Gitea: Поддержка федеративных запросов на вытягивание

_От @roblabla 25 мая 2016 г., 12: 9_

В некоторой степени связано: https://github.com/gogits/gogs/issues/2210

Это особенность номер один для персонального размещенного сервиса Git!
Было бы еще лучше с # 185!

Это тоже можно интегрировать с интеграцией git-appraise?

Формальные предложения @ekozan приветствуются, но я вижу, что интеграция с git-appraise может быть хорошим компаньоном для федеративных запросов на вытягивание (чтобы обзоры перемещались по федеративным узлам вместе с остальной частью кода, верно?)

GitLab отслеживает эту проблему здесь , так что, возможно, вы могли бы описать оптимизированный рабочий процесс. Они планируют упомянуть об этой особенности во время своего саммита.

@bkcsoft, может быть, вы поможете сохранить спецификации GitLab достаточно открытыми, чтобы можно было объединить PR между GitLab и Gitea?

@strk является @bkcsoft связан с GitLab?

@strk Я мог бы направить его в сторону простой отправки файлов патчей между серверами (может быть, с помощью веб-перехватчиков?). Я предлагаю, чтобы это сделала и Гитеа. Делает это действительно _ простым, без необходимости толкать / тянуть между серверами :)
@stevenroose Да

Что ж, похоже, они уже думают или используют git request-pull -p (который отправляет патч), поэтому он должен быть кроссплатформенным: слегка_smiling_face:

Они планируют упомянуть об этой особенности во время своего саммита.

https://gitlab.com/gitlab-org/gitlab-ce/issues/4013 помечен как moonshot , неназначен, нет вехи и нет MR в поле зрения. Так что, может быть, еще не надейтесь:

@bkcsoft Мы могли бы взять на себя инициативу здесь :) Если мы сможем включить GitLab и GitHub, это положит конец блокировке, налагаемой в настоящее время этими платформами.

@bkcsoft Мы могли бы взять на себя инициативу здесь :) Если мы сможем включить GitLab и GitHub, это положит конец блокировке, налагаемой в настоящее время этими платформами.

Я не могу поверить, что GitHub хочет решить проблему блокировки: P

Нет, но если другие платформы будут лидировать, люди могут потребовать, чтобы они последовали за ними. И люди могут мигрировать :)

Программное обеспечение вроде Gerrit позволяет это

@stevenroose у вас есть упоминание о поддержке Gerrit?

Если мы реализуем Gerrit, можем ли мы пригласить команду Golang использовать Gitea? 😄

@strk Используя Gerrit, вы упаковываете свои коммиты с помощью git-review и отправляете их определенной ссылке, и это будет отображаться в Gerrit как проверка кода. Нет необходимости создавать вилку Gerrit. Однако он не использует git request-pull .

Вам все равно понадобятся разрешения на запись в репо, чтобы подтолкнуть эти
отзывы к реф, да?

В этом случае недостающий бит все равно будет отслеживаться
другое репо с рецензией?

Да, это другое. Он выдвигает отдельные биты с разрешением на запись.

При использовании федеративных PR Gitea должна периодически (или по запросу) проверять ссылку на ветку на предмет новых изменений.

AFAIK, git request-pull вообще не использует коммиты git. Он просто генерирует список коммитов между локальным и удаленным и выводит его на стандартный вывод. Нам нужно будет указать способ отправки этих изменений на пульты / для их извлечения с пультов.

Однако Git request-pull является частью стандартной установки git, в отличие от git appraise или git review.

@roblabla Да, поток будет заключаться в том, чтобы сохранить git request-pull в файл и загрузить его (например, как отправка исправлений работала в прошлом). Или введите URL-адрес ветки удаленного репо, чтобы Gitea могла обновить PR.

Если мне не хватает чего-то git request-pull ссылающегося на конкретную фиксацию,
в то время как запросы на вытягивание github / gitea ссылаются на (возможно, движущуюся) ветку.

Хотим ли мы, чтобы федеративный запрос отслеживал ветки, а не конкретные коммиты?
Я думаю, нам нужен PR (ветка комментариев / обсуждения) для отслеживания ветки.

он ссылается на конкретные _commit_ да. Поэтому нам нужно будет постоянно получать данные заново 😒

Во вторник, 20 декабря 2016 г., в 00:20:34 -0800, bkcsoft написал:

он ссылается на конкретные _commit_ да. Поэтому нам нужно будет постоянно получать данные заново 😒

Мы можем получить новые коммиты, только если у нас есть ссылка на имя ветки,
которого нет в выводе git request-pull . Итак, если мы хотим сохранить
track-a-branch подход, мы не можем полагаться на git request-pull .

Создатель PR может запросить удаленный URL-адрес и название ветки, проверьте
удаленного филиала локально, выполните некоторые проверки (например: откажитесь от создания PR с помощью
огромное количество изменений) и создадим пиар.

Затем можно было бы сделать доступными кнопку и веб-перехватчик, чтобы получать больше
совершает, если есть, из удаленной ветки. Только автор PR должен быть
учитывая возможность запрашивать обновления. Поместите git-крючок на его вилку
попадание в целевой веб-перехватчик упростит процесс обновления.

--strk;

Я бы посоветовал, чтобы при создании PR в качестве гостевой учетной записи у вас была вкладка с «внешним» или «федеративным» или с чем-то еще, что имеет два варианта:

1. поле ввода текста для URL-адреса ветки с кнопкой «выборка» или «проверка», возможно, для проверки доступности и доступности отслеживания

2. поле загрузки файла для загрузки файла .diff , .patch или вывода git-request-pull ; это также может быть текстовое поле

В последнем случае, как только PR создан, пользователи должны иметь возможность перезаписать свой предыдущий файл, чтобы изменить коммиты в PR.

Кроме того, в случае недоступности автоматических обновлений веток вы можете потребовать, чтобы пользователь вручную запускал повторную выборку. Почти во всех случаях пользователи совершают фиксацию в PR-ветке исключительно в свете фиксации, поэтому они могут просто повторно выполнять выборку всякий раз, чтобы обновить ветку. (Учтите, что часто обновления коммита происходят из-за обратной связи в PR, поэтому страница у них в любом случае открыта.)

Как выразился автор моей диссертации: «Настоящее сопротивление переменам исходит не от людей, которые против них, а от людей, которые постоянно говорят, что этого недостаточно».

Я не думаю, что эта функция полезна, вы можете добавить два пульта для этого случая. например ветка github для gh, master для gogs, я использую оба в своей работе с одним репозиторием. и git review - другое дело. не создавайте больших возможностей для решения небольших проблем.
так или иначе, изумленные взгляды сосредотачиваются на малом бизнесе или самостоятельном хостинге. не для общедоступной облачной службы.

@renothing Я не думаю, что вы полностью понимаете это предложение. Это не имеет ничего общего с возможностью сравнивать или проверять код из разных удаленных источников. Вместо этого речь идет о том, чтобы позволить людям отправлять запросы на вытягивание или исправления без регистрации в вашей системе. Если я публикую часть программного обеспечения в моем экземпляре Gitea, я хочу, чтобы другие могли создавать PR, не требуя от них прохождения через регистрацию, разветвление, отправку своих изменений в мой экземпляр, а затем создание PR.

@stevenroose
как я уже сказал, это довольно маленькая сцена спроса. Подумайте, скольким людям нужно объединить PR с сутью? Я не считаю необходимым добавлять эту функцию в ядро ​​gitea. возможно, это нормально для плагина, когда архитектура плагина gitea готова.

@renothing Если я правильно понимаю проблему, которая здесь решается, она выходит далеко за рамки простого слияния. Он занимается слиянием нескольких разных экземпляров gitea и даже между репозиторием GitHub и репозиторием на экземпляре gitea. Это позволяет объединять изменения из любой удаленной ветки на любом поддерживаемом сервере git в Интернете.

@stevenroose Поправьте меня, если я ошибаюсь: smiley:

@sbrl
вы правы, но если кто-то хочет внести свой вклад в ваше репо, ему сначала нужно будет получить ваш код, он должен сохранить два удаленных (один для себя, один для вас). это нисколько не уменьшило работ. эта функция просто сокращает шаг входа / регистрации. это не слишком помогло, возможно, путь отправки электронной почты - лучший выбор, как ядро ​​Linux.

я не в порядке с тобой @renothing

1. Когда вы работаете с git, у вас всегда много удаленных
2. Это должно быть
3. шаг входа в систему чертовски скучен
4. gitlab тоже сделает это: https://gitlab.com/gitlab-org/gitlab-ce/issues/4013
5. это основная функция, поэтому это не плагин

В любом случае я полностью за поддержку федеративных запросов на вытягивание
Я не думаю, что они могут заменить вход в систему, как вы все еще хотите
как-то предоставлять / отзывать разрешения на создание PR и комментирование
соответствующий поток.

О входе в систему должен позаботиться OpenID Login (там
еще один билет об этой части).

@renothing Насколько я могу судить, на самом деле это будет сервер, который автоматически извлекает код с пульта дистанционного управления, а это означает, что чувак, выполняющий запрос на перенос, просто должен нажать на ветку на своем собственном сервере и не Не обязательно иметь 2 пульта (Опять же, поправьте меня, если я ошибаюсь).

Кроме того, если вам это не нравится, я уверен, что будет возможность отключить его - никто вам не говорит, что вы должны его использовать: smiley:

Действительно. Вы могли использовать GitHub, я использую свой собственный Gitea. Если вы хотите внести свой вклад в мой проект, я не хочу, чтобы у вас была учетная запись в моем экземпляре Gitea, потому что вы используете GitHub. Я хочу, чтобы вы поместили функцию в ветку своего репо на GitHub, затем вернулись к моему экземпляру, домашней странице проекта, и отправили PR из своей ветки GitHub в главную. Если вам не нужно создавать учетную запись, все, что вам нужно сделать, это войти в систему с помощью своей учетной записи GitHub (возможно, сделать CAPTCHA) и вставить URL-адрес в свою ветку GitHub.

Как я, возможно, заметил в другом PR (OpenID), даже если кто-то регистрирует
с механизмом удаленной аутентификации (OpenID в моем случае GitHub / OAuth2
в примере, который вы делаете) ему все еще нужна запись в локальном экземпляре,
если не возможность участвовать в обсуждении предложенного им
изменения, и, возможно, получите уведомление по почте с ответами.

Таким образом, разрешение ссылаться на ветки на удаленных серверах git в основном связано с
сделать с устранением необходимости предоставлять участнику разрешение на
и фактически создать новый репозиторий git для кода, который он уже размещает
где-нибудь еще. Чтобы предоставить в основном свободу размещения вилок на произвольных
хостеры.

Возможно, однажды мы получим достаточно детализированных разрешений, чтобы иметь возможность
иметь пользователей, которые могут отправлять PR, но не могут создавать локальные репозитории / вилки.

Чтобы не усложнять ядро ​​gitea, мне совсем не нравится эта функция. это сделает основные функции более сложными, не только систему запросов на вытягивание, но и систему разрешений, а также затруднит интеграцию с третьей системой CI. в любом случае, основные авторы имеют право выбора.

@renothing Ну, не главные авторы должны выбирать, а пользователи.

Что касается CI, я не думаю, что это проблема. Что делает CI, так это просто тянет ветку и запускает несколько скриптов. Поскольку система CI, вероятно, в любом случае отделена от экземпляра Gogs, на самом деле нет никакой разницы в извлечении ветки из репозитория Gogs или из любого другого удаленного репо.

Кроме того, в любом случае должна существовать система разрешений. Но это не должно быть сложнее, чем просто установить дополнительный флажок для «Гостевые учетные записи». У вас есть такие разрешения, как _commit, создавать проблемы, делать PR и комментировать_, и тогда у вас будет три типа пользователей _ участники репо, зарегистрированные учетные записи в Gogs и гости_. Ez πz

Идея единого флага для «гостевой учетной записи» кажется интересной.
Но тогда ни один гость не мог бы «наблюдать» за изменениями, верно?

Вы бы подавали федеративный PR и не получали комментариев по нему, если только
ваша электронная почта (и настройки) известны системе.

Согласны ли вы, что для пользователя в любом случае должна быть создана локальная запись?

@strk. Ты бы. Гости входят в систему с помощью OpenID, поэтому их адрес электронной почты будет известен. Пользовательская база данных должна просто различать «настоящих» пользователей и гостевых.

Говоря «не член этого экземпляра», я не имел в виду, что их вообще не было в базе данных.

Вам все равно нужно знать, какой адрес электронной почты (и, следовательно, пользователя) следует уведомлять при получении комментариев к заявке, поэтому должна быть связь между заявкой (PR) и «пользователем» (гостем или нет) - это означает, что у вас все еще есть запись в базе данных для этой ассоциации.

Кстати, адрес электронной почты, предоставленный OpenID, не обязательно должен доверять / подтверждаться, поэтому, если вы хотите быть уверенным в электронной почте, вам все равно нужно позаботиться об этом.

Интересный дизайнерский документ от NotABug, люди с идеями о федеративной службе хостинга git: https://notabug.org/NotABug.org/notabug/src/master/README.md

OAuth для GH / BB / GL можно использовать для привязки однократной учетной записи, тогда, если вы разрешите это, Gitea перечислит ваши удаленные репозитории и ветки, и вы можете создавать PR для любого репо, имеющего общего предка (найти это будет такой болью. ..). Единственная проблема, которую я вижу, это то, что _все_ другие системы (GitHub, BitBucket, GitLab) имеют разные API для получения этих данных, нам нужно поддерживать все или ни одного. Я говорю плагины: trollface:

@strk Этот проектный документ выглядит хорошо в теории, но на практике его никто не поддерживает (по крайней мере, GH / BB / GL этого не делает, не стесняйтесь указывать на кого-то, кто это делает, ИЛИ, по крайней мере, _actuall_ намеревается сделать это), поэтому в на самом деле это в основном пустяки, пока хотя бы один другой не реализовал это.
Этому можно противопоставить «но мы могли бы быть первыми!», Если мы первые, а затем все остальные остановятся на другом «стандарте», мы останемся в затруднительном положении и нам придется взять время _персонального хобби_, чтобы заменить наш существующий поток указанным другим стандартом. , возможно, нарушив текущий поток. Если вместо этого мы воспользуемся какой-то существующей техникой, которая вроде бы жизнеспособна, а другие остановятся на чем-то, мы могли бы ее реализовать. Но до указанного времени я бы воздержался от введения «федерации», если она не совсем федеративная. Сделай один раз, и сделай правильно 🙂

Это действительно проблема курицы и яйца. Пока кто-то не внедрит федерацию, никто не будет внедрять федерацию.

РЕДАКТИРОВАТЬ: Я также утверждаю, что если мы сможем объединить экземпляры gogs, мы уже сделали первый шаг к федерации.

@roblabla Верно, я не против

Я бы предпочел универсальное решение тому, которое связано с известным API, особенно от проприетарных сервисов.

Я согласен с @strk. Сам по себе Git довольно мощный, я бы постарался максимально использовать основные функции Git.

Если федерация реализована, например, на основе URI Git, добавление сахара пользовательского интерфейса для хостинг-провайдеров не так уж и сложно. Для Gitea мы используем наши собственные API для извлечения информации из PR. Для GH / GL / ... мы либо не можем их поддерживать, поэтому просто поддерживаем копирование и вставку URI Git, либо реализуем виджет пользовательского интерфейса для извлечения этих URI из API. Или, что еще проще, сопоставьте URL-адреса PR с URI Git.

Одна из проблем заключается в том, что, насколько мне известно, нет стандартного способа представления ветки в удаленном репо. Я думаю, что раньше видел git://provider/repo.git#refs/mybranchref , но не уверен, насколько это стандартно.

В среду, 22 марта 2017 г., в 09:47:06 -0700 Стивен Руз написал:

Одна из проблем заключается в том, что, насколько мне известно, нет стандартного способа представления ветки в удаленном репо. Я думаю, что раньше видел git://provider/repo.git#refs/mybranchref , но не уверен, насколько это стандартно.

Я не понимаю, почему это проблема.
Просто скажите, что для отправки "федеративного запроса на перенос" у вас будет
чтобы предоставить всю информацию, которую "git request-pull" просит вас
предоставлять ...

Это не обязательно должен быть один URL, это может быть и целая форма ...

Как насчет того, чтобы попросить GH / GL высказать свое мнение о предлагаемом стандарте? Может быть открытием для более широкой дискуссии на эту тему

Конечно, но нам сначала нужен предлагаемый стандарт ...

Система Pagure (https://pagure.io/pagure) поддерживает удаленный запрос на вытягивание, который я нашел полезным при работе с репозиторием пакетов Fedora. Вам необходимо быть зарегистрированным, чтобы сделать удаленный запрос на вытягивание.

См. Https://docs.pagure.org/pagure/usage/pull_requests.html#remote -git-to-pagure-pull-request

По теме: https://github.com/gogits/gogs/issues/4437

Есть новости по этому поводу? В настоящее время в новостях много говорится о приобретении Github Microsoft, поэтому федерация в контексте веб-службы git была бы очень крутой :)

Я буквально пришел искать эту проблему за минуту до того, как увидел уведомление из вашего комментария. Это (и федеративные запросы на вытягивание) - действительно потрясающая функция для следующей платформы Git. Я вижу вкладку входа в систему OpenID, но она не очень удобна для пользователя с точки зрения легкого доступа к крупным поставщикам OpenID, таким как Google. Я видел только исключение для GitHub.

Всем привет. Я обнаружил эту проблему, когда смотрел, что было сделано в отношении федеративных инфраструктур git после покупки GitHub корпорацией Майкрософт.

Когда дело доходит до объединения идентификаторов пользователей, комментариев, активности ... и, я полагаю, запросов на вытягивание / слияние, я думаю, что выполнение этого с использованием стандарта ActivityPub сделает даже больше, чем просто объединение инфраструктур git вместе: это объединит инфраструктуры git с другими ActivityPub реализации. Например, он может позволить вам комментировать пул-реквест в экземпляре Mastodon , чтобы следить за отчетом об ошибке в видео в экземпляре PeerTube или в виде слайдов в экземпляре MediaGoblin с билетом в экземпляре GitLab. …

Мои 2 cts;)

Присоединяясь к тому, что написал @Arkanosis : похоже, это то, к чему стремится

Подобная спецификация должна быть согласована по крайней мере с некоторыми реализациями веб-сервисов Git. Если вы разработчик такого программного обеспечения, присоединяйтесь к нашему обсуждению и высказывайтесь. Мы просто добавим вас в рабочую группу.

Я не уверен, что комментарий @Arkanosis применим и к диаспоре, но он определенно был бы полезен для меня, если бы это было так! С нетерпением жду этой функции! :)

Я не уверен, что комментарий @Arkanosis применим и к диаспоре.

@KingDuckZ : Желаю! Однако в последний раз, когда я проверял, Diaspora не внедряла ActivityPub. Мне бы очень хотелось, чтобы это стало федерацией с другими сетями (особенно с Мастодонтом). Это, в качестве дополнительного преимущества, значительно упростит объединение диаспоры и всего, что выйдет из этого предложения (GitPub или что-то еще).

Конечно, можно было бы напрямую вступить в федерацию с диаспорой, используя протокол федерации диаспоры (веб-пальцы + микроформаты + другие), но этот протокол, похоже, не пользуется такой популярностью, как ActivityStreams / ActivityPub.

Пожалуйста, продолжайте тему. Эта проблема связана только с возможностью открывать запросы на вытягивание из удаленных репозиториев. Все, что нужно для этого, - это обычная формулировка «репо и ветвь».

Примером может быть https://github.com/go-gitea/gitea.git#federated-prs .

Объединение других данных, таких как вопросы и комментарии, выходит за рамки этого. Я думаю, что в качестве первого шага вы должны иметь возможность сделать PR, не создавая учетную запись в репозитории git.

@stevenroose, если вы обратитесь ко мне: извините, мне действительно следовало бы поместить его в # 1612. Между тем кто-то еще упомянул об этом там.

Сейчас существует рабочая группа / проект по разработке протокола федерации git на основе ActivityPub. https://github.com/git-federation/gitpub

Присоединяйтесь к их списку рассылки, если вам интересно.

GitLab это реализует!
https://gitlab.com/gitlab-org/gitlab-ce/issues/40830
https://gitlab.com/groups/gitlab-org/-/epics/260

Niiiice!

Федеративный мерзавец был бы великолепен. Не люблю регистрировать бесчисленные учетные записи для репозиториев git ...
Федеративные PR и выпуски! 👍

@pwFoo Я думаю, что потребуется время, чтобы это указать и реализовать.

Не люблю регистрировать бесчисленные учетные записи для репозиториев git ...

Будет ли у вас вариант «Войти через GitHub», если до этого достаточно одного щелчка мышки?

Может быть обходным путем, но цель должна быть объединена в проблемы / PR, федеративные социальные сети (mastodon, pleroma, misskey, ...) в будущем.

Может быть обходным путем, но цель должна быть объединена в проблемы / PR, федеративные социальные сети (mastodon, pleroma, misskey, ...) в будущем.

Какой от этого вариант использования? Сдавление gitea для принудительного обмена информацией между платформами ActivityPub и GitFed или любым другим решением, созданным здесь, приведет к чрезмерной инженерии.

@jalcine Вариант использования заключается в том, что если вы работаете над несколькими разными программными проектами, вам не нужно создавать и поддерживать учетную запись на всех платформах, на которых размещены эти проекты (GitHub, GitLab или их собственный Gitea / GitLab / что бы ни). В идеале у вас есть собственное репо (GitHub, GitLab или ваш собственный Gitea), и вы можете делать PR для всех проектов, над которыми вы работаете, из собственного репо.

Верно, но то, что человек, которому я отвечал, говорил, что вы войдете с помощью Мастодонта в Гитею?

В моем случае у меня есть экземпляр Gitea на домашнем сервере. Мой raspberry pi и мое подключение к Интернету имеют ограниченные ресурсы. И я хочу, чтобы боты не могли создавать учетные записи, чтобы у меня было меньше администрирования в свободное время.

Из-за этого я отключил страницу регистрации. Таким образом, никто не может добавлять проблемы в мои общедоступные репозитории.

В настоящее время единственный способ получать проблемы от людей - использовать зеркальный репозиторий на Github. Но тогда я могу закрыть свой экземпляр Gitea.

Единственный способ, в котором Gitea будет лучше, чем Github, - это поддержка федеративных задач и запросов на вытягивание (принцип децентрализации).

Социальные сети, такие как mastodon, - это еще одна тема, которую приятно иметь.

Но федеративные задачи и запросы на вытягивание являются обязательными, поэтому людям не нужно беспокоиться о создании учетной записи в каждом случае, например Nextcloud / Owncloud.

@jalcine
"Объединенный git был бы великолепен. Не люблю регистрировать бесчисленные учетные записи для репозиториев git ...
Федеративные PR и выпуски! 👍 "

Цель не в том, чтобы войти в систему с помощью GitHub или Mastodon Account ... Я процитировал свой ответ.
Цель состоит в том, чтобы использовать одну учетную запись (в идеале - мою собственную), чтобы открывать вопросы, отвечать или открывать PR.

Я заблокировал эту проблему, так как в настоящее время она обсуждается в списке рассылки подделок, пожалуйста, перенаправьте все разговоры туда.

Подробнее: https://github.com/forgefed/forgefed