Gitea: フェデレーションプルリクエストをサポートする

_ 2016年5月25日の@roblablaから12：9_

やや関連： https ：

これは、個人がホストするGitサービスの最大の機能です。
＃185でさらに大きくなるでしょう！

これはgit-appraise統合とも統合できますか？

@ekozanの正式な提案は大歓迎ですが、git-

GitLabはここでこの問題を追跡しているので、合理化されたワークフローを説明できるかもしれません。 彼らはサミット中にその機能について言及することを計画しています。

@bkcsoft多分あなたはGitLabとGiteaの間でPRをフェデレーションすることを可能にするのに十分にGitLabスペックを開いたままにするのを手伝うことができますか？

@strkはGitLabと提携していますか？

@strkサーバー間でパッチファイルを送信する方向に操作できます（おそらくWebhookを使用しますか？）。 これは、Giteaも行うべきだと私が提案することです。 サーバー間でプッシュ/プルする必要がないことを_本当に_簡単にします:)
@stevenrooseはい

まあ、彼らはすでにgit request-pull -p （パッチを送信します）を考えているか使用しているようですので、クロスプラットフォーム互換である必要があります：slightly_smiling_face：

彼らはサミット中にその機能について言及することを計画しています。

https://gitlab.com/gitlab-org/gitlab-ce/issues/4013は、 moonshotとしてタグ付けされており、割り当てられておらず、マイルストーンもMRも見えません。 だから、まだあなたの希望を上げていないかもしれません：slightly_smiling_face：

@bkcsoftここで主導

@bkcsoftここで主導

GitHubがロックインの問題を解決したいと思っているなんて信じられません：P

いいえ。ただし、他のプラットフォームが先導している場合、人々は彼らが従うことを要求するかもしれません。 そして人々は移住するかもしれません:)

Gerritのようなソフトウェアはそれを可能にします

@stevenroose Gerritのサポートについてのリファレンスはありますか？

Gerritを実装する場合、GolangチームにGiteaを使用するように招待できますか？ 😄

@strk Gerritでは、 git-reviewを使用してコミットをパッケージ化し、それらを特定の参照にプッシュすると、コードレビューとしてGerritに表示されます。 Gerritフォークを作成する必要はありません。 ただし、 git request-pullは使用しません。

それらをプッシュするには、リポジトリへの書き込み権限が必要です
参照へのレビュー、そうですか？

その場合、欠落しているビットは最終的に追跡されます
レビュー参照を保持している別のリポジトリ？

ええ、それは違います。 書き込み権限で個々のビットをプッシュします。

フェデレーションPRの場合、Giteaは定期的に（または要求に応じて）ブランチリファレンスをチェックして新しい変更を確認する必要があります。

AFAIK、gitrequest-pullはgitcommitをまったく使用しません。 ローカルとリモート間のコミットのリストを生成し、それをstdoutに出力するだけです。 これらの変更をリモートに送信する方法/リモートからプルする方法を指定する必要があります

Gitリクエストプルは、gitappraiseやgitreviewとは異なり、標準のgitインストールの一部です。

@roblablaええ、フローはgit request-pullをファイルに保存し、それをアップロードすることです（パッチの送信が以前どのように機能していたかなど）。 または、リモートリポジトリのブランチへのURLを入力して、GiteaがPRを更新できるようにします。

git request-pullが特定のコミットを参照しているものがない限り、
一方、github / giteaプルリクエストは（移動している可能性のある）ブランチを参照します。

特定のコミットではなく、フェデレーションリクエストでブランチを追跡する必要がありますか？
ブランチを追跡するためのPR（コメント/ディスカッションのスレッド）が必要だと思います。

特定の_commits_yesを参照します。 したがって、データを継続的に再フェッチする必要があります😒

2016年12月20日火曜日12:20:34 AM -0800、bkcsoftは次のように書いています。

特定の_commits_yesを参照します。 したがって、データを継続的に再フェッチする必要があります😒

ブランチ名への参照がある場合にのみ、新しいコミットをフェッチできます。
これはgit request-pull出力にはありません。 だから私たちが維持したい場合
track-a-branchアプローチでは、 git request-pull依存することはできません。

PR作成者は、リモートURLとブランチ名を要求できます。
ローカルにリモートブランチし、いくつかのチェックを実行します（つまり、PRの作成を拒否します）
膨大な数の変更）、PRを作成します。

次に、ボタンとWebhookを使用可能にして、さらにフェッチすることができます。
リモートブランチからコミットします（存在する場合）。 PRの作者だけが
更新を要求する機能が与えられます。 フォークにgitフックを配置する
宛先のWebhookにアクセスすると、更新エクスペリエンスがスムーズになります。

--strk;

ゲストアカウントとしてPRを作成するときは、「外部」または「フェデレーション」など、次の2つのオプションがあるタブを作成することをお勧めします。

1. ブランチURLのテキスト入力フィールド。「フェッチ」または「テスト」ボタンがあり、追跡の到達可能性と可用性を確認できます。

2. .diff 、 .patchファイルまたはgit-request-pullの出力をアップロードするためのファイルアップロードフィールド。 これもテキストエリアである可能性があります

後者の場合、PRが作成されると、ユーザーはPRのコミットを変更するために、以前のファイルを上書きできるようになります。

また、自動ブランチ更新が利用できない場合は、ユーザーに手動で再フェッチをトリガーするように要求することができます。 ほとんどすべての場合、ユーザーはコミットに照らして排他的にPRされたブランチにコミットするため、ブランチを更新するたびに再フェッチすることができます。 （多くの場合、コミットの更新はPRでのフィードバックが原因であるため、とにかくページが開いていることを考慮してください。）

私の論文の推進者が述べたように、「変化に対する本当の反対は、それに反対する人々からではなく、それだけでは不十分だと言い続ける人々から来る」。

この機能は役に立たないと思います。この場合、2つのリモコンを追加できます。 たとえば、ghのブランチgithub、gogsのマスター、1つのリポジトリでの作業で両方を使用します。 そしてgitレビューは別のものです。 小さな問題を解決するために大きな機能を作らないでください。
とにかく、ゴグは中小企業やセルフホスティングに焦点を当てています。 パブリッククラウドサービス用ではありません。

@renothingあなたはその提案を完全には理解していないと思います。 さまざまなリモートソースからのコードを比較またはチェックアウトできることとは何の関係もありません。 代わりに、システムに登録しなくても、プルリクエストやパッチを送信できるようにすることです。 私がGiteaインスタンスでソフトウェアを公開する場合、他の人が登録、フォーク、変更をインスタンスにプッシュしてからPRを作成する手間をかけずに、PRを作成できるようにしたいと思います。

@stevenroose
私が言ったように、それはかなりの需要シーンです。 考えてみてください。要点からPRをマージする必要があるのは何人ですか？ この機能をgiteaコアに追加する必要はないと思います。 giteaプラグインアーキテクチャの準備ができたら、プラグインは問題ないかもしれません。

@renothingここで正しく取り組まれている問題を理解していれば、単純な要点をマージするだけではありません。 複数のgiteaの異なるインスタンス間、さらにはGitHubリポジトリとgiteaインスタンス上のリポジトリ間のマージに取り組みます。 これにより、インターネット上でサポートされているgitサーバー上の任意のリモートブランチからの変更をマージできます。

@stevenroose間違っている場合は訂正してください：smiley：

@sbrl
あなたは正しいですが、誰かがあなたのリポジトリに貢献したい場合、彼は最初にあなたのコードをフェッチする必要があります、彼は2つのリモートを維持する必要があります（1つは自分用、もう1つはあなた用）。 それは仕事を全く減らしませんでした。 この機能は、ログイン/登録のステップを減らすだけです。 それはあまり役に立ちませんでした、多分電子メールパスを送ることはLinuxカーネルのようにより良い選択です。

私はあなたに大丈夫ではありません@renothing

1. gitを使用する場合、常に多くのリモートがあります
2. それは持っている必要があります
3. ログイン手順は退屈です
4. gitlabもそれを行います： https ：//gitlab.com/gitlab-org/gitlab-ce/issues/4013
5. これは主な機能なので、プラグインではありません

とにかく、フェデレーションプルリクエストをサポートしてくれてありがとう
あなたがまだ望むので、私は彼らがログインを置き換えることができるとは思わない
どういうわけかPRを提出し、コメントするための許可を付与/取り消す
対応するスレッド。

ログイン部分はOpenIDログインで処理する必要があります（
その部分に関する別のチケット）。

@renothing私が知る限り、実際には、リモートからコードを自動的にフェッチするのはサーバーです。つまり、プルリクエストを実行する

その上、それが気に入らない場合は、それを無効にするオプションがあると確信しています-誰もあなたがそれを使用しなければならないとあなたに言っていません：smiley：

それはそう。 あなたはGitHubを使用したかもしれません、私は私自身のGiteaを使用します。 私のプロジェクトに貢献したい場合は、GitHubを使用しているため、Giteaインスタンスにアカウントを持たせたくありません。 機能をGitHubのリポジトリのブランチにプッシュしてから、私のインスタンスであるプロジェクトのホームページに戻って、GitHubブランチからマスターブランチにPRを提出してください。 アカウントを作成しなくても、GitHubアカウントでログインして（おそらくCAPTCHAを実行して）、URLをGitHubブランチに貼り付けるだけです。

誰かがログに記録したとしても、別のPR（OpenIDのもの）で観察されたかもしれません
リモート認証メカニズム（私の場合はOpenID、GitHub / OAuth2
あなたが作成した例では）彼はまだローカルインスタンスへのレコードを必要としています、
他にない場合は、彼の提案についての議論に参加することができます
変更され、回答がメールで通知される場合があります。

したがって、リモートgitサーバー上のブランチを参照できるようにすることは、ほとんどの場合、
寄稿者に許可を与える必要をなくすことで行う
彼がすでにホストしているコード用の新しいgitリポジトリを実際に作成します
何処か別の場所。 基本的に任意のフォークをホストする自由を与えるため
ホスティング業者。

たぶんいつの日か、私たちはできるように十分にきめ細かい許可を得るでしょう
PRを送信できるが、ローカルリポジトリ/フォークを作成できないユーザーがいること。

giteaコアをシンプルに保つために、私はこの機能がまったく好きではありません。 プルリクエストシステムだけでなく、パーミッションシステムも備えており、3番目のCIシステムとの統合が困難になるため、コア機能がより複雑になります。 とにかく、主な作者は選択する権利を持っています。

@renothingええと、主な作者は選択すべきものではなく、ユーザーが選択すべきです。

CIでは、それは問題ではないと思います。 CIが行うことは、ブランチをプルしていくつかのスクリプトを実行することです。 CIシステムはおそらくGogsインスタンスから分離されているため、Gogsリポジトリまたは他のリモートリポジトリからブランチをプルしても実際には違いはありません。

また、とにかく許可システムを設置する必要があります。 ただし、「ゲストアカウント」のチェックボックスを追加するよりも複雑なことはありません。 _commit、問題の作成、PRとコメントの作成_などの権限があり、3種類のユーザー_リポジトリのメンバー、Gogsの登録済みアカウント、Guests_があります。 Ezπz

「ゲストアカウント」の単一フラグのアイデアは興味深いようです。
しかし、そうすると、ゲストが変更を「監視」することはできませんよね？

あなたはフェデレーションPRを提出し、それについてのコメントを受け取らないでしょう。
あなたの電子メール（および設定）はシステムによって認識されます。

とにかくユーザーのためにローカルレコードを作成する必要があることに同意しますか？

@strk。 するでしょう。 ゲストはOpenIDでログインするため、ゲストの電子メールアドレスがわかります。 ユーザーデータベースは、「実際の」ユーザーとゲストユーザーを区別するだけです。

「このインスタンスのメンバーではない」ということは、データベースにそれらの記録がまったくないという意味ではありませんでした。

チケットに関するコメントを受け取ったときに通知する電子メール（したがってユーザー）を知る必要があるため、チケット（PR）と「ユーザー」（ゲストかどうか）の間に関連付けが必要です-これは、まだ持っていることを意味しますその関連付けのデータベース内のレコード。

ところで、OpenIDが提供する電子メールは必ずしも信頼/確認されているわけではないので、電子メールについて確実にしたい場合でも、それを処理する必要があります

フェデレーションgitホスティングサービスに関するアイデアを持つNotABugの人々による興味深い設計ドキュメント： https ：//notabug.org/NotABug.org/notabug/src/master/README.md

GH / BB / GLのOAuthを使用して、1回のアカウントをリンクできます。許可すると、Giteaはリモートリポジトリとブランチを一覧表示し、共通の祖先を持つリポジトリへのPRを作成できます（これは非常に面倒です。 ..）。 私が見ている唯一の問題は、他のシステム（GitHub、BitBucket、GitLab）がこのデータをフェッチするための異なるAPIを持っていることです。すべてをサポートするか、まったくサポートしない必要があります。 私はプラグインと言います：trollface：

@strkその設計ドキュメントは理論的には見栄えがしますが、実際には誰もそれをサポートしていません（少なくとも、GH / BB / GLはサポートしていません。サポートしている人を自由に指摘してください。または、少なくともそうする意図があります）。現実には、少なくとも1人が実装するまでは、主に雑学です。
「しかし、私たちが最初になる可能性があります！」と反論する人もいるかもしれません。私たちが最初で、他のすべての人が別の「標準」に落ち着くと、立ち往生し、既存のフローを他の標準に置き換えるために_個人的な趣味の時間_を費やす必要があります。 、おそらく電流の流れを壊します。 代わりに、ある種の実行可能な既存の手法を使用し、他の手法を使用して、代わりにそれを実装できるものに落ち着く場合。 しかし、その時まで、正確にフェデレーションされていない「フェデレーション」の導入は控えていました。 一度やれば、正しくやる🙂

これは本当に鶏が先か卵が先かという問題です。 誰かがフェデレーションを実装するまで、誰もフェデレーションを実装しません。

編集：私はまた、gogsインスタンス間でフェデレーションを行うことができれば、フェデレーションに向けた第一歩を踏み出したと主張します。

@roblablaそうです、私はインスタンス間でのプルリクエストに反対していませんが、私が言っているのは、さまざまなプロバイダーAPIなどの_既存の機能を使用する_です:)

特にプロプライエタリサービスからの既知のAPIにバインドされているソリューションよりも一般的なソリューションの方がいいと思います。

@strkに同意します。 Git自体は非常に強力です。可能な限り、Gitのコア機能に頼ろうと思います。

フェデレーションがGitURIに基づいて実装されている場合、ホスティングプロバイダーにUIシュガーを追加することはそれほど難しくありません。 Giteaの場合、PRから情報を抽出するために独自のAPIを使用します。 GH / GL / ...の場合、それらをサポートできないため、コピーアンドペーストのGit URIをサポートするか、UIウィジェットを実装してAPIからこれらのURIを取得します。 または、さらに簡単に、PRURLをGitURIにマップします。

1つの問題は、私が知る限り、リモートリポジトリでブランチを表す標準的な方法がないことです。 以前にgit://provider/repo.git#refs/mybranchrefを見たと思いますが、それがどれほど標準的かはわかりません。

2017年3月22日水曜日09:47:06 AM -0700に、StevenRooseは次のように書いています。

1つの問題は、私が知る限り、リモートリポジトリでブランチを表す標準的な方法がないことです。 以前にgit://provider/repo.git#refs/mybranchrefを見たと思いますが、それがどれほど標準的かはわかりません。

それがどのように問題なのかわかりません。
「フェデレーションプルリクエスト」を送信するには、
「gitrequest-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がMicrosoftに買収されているというニュースがたくさんあるので、gitWebサービスのコンテキストでのフェデレーションは非常にクールです:)

あなたのコメントからの通知を見る1分前に、私は文字通りこの問題を探しに来ました。 これ（およびフェデレーションプルリクエスト）は、実際には次のGitプラットフォームのキラー機能です。 OpenIDログインタブが表示されますが、Googleのような大手OpenIDプロバイダーに簡単にアクセスできるという点であまりユーザーフレンドリーではありません。 GitHub用に作成された例外を見ただけです。

皆さんこんにちは。 MicrosoftがGitHubを購入した後、フェデレーションgitインフラストラクチャに関して何が行われていたかを調べているときにこの問題を見つけました。

ユーザーID、コメント、アクティビティのフェデレーションに関しては、プル/マージリクエストも同様だと思いますが、 ActivityPub標準を使用して行うと、gitインフラストラクチャを他のActivityPubとフェデレーションするだけではありません。実装。 たとえば、 MastodonインスタンスからのGiteaインスタンスのプルリクエストにコメントしたり、 PeerTubeインスタンスの動画内のバグレポートや、 GitLabインスタンスのチケットを使用したMediaGoblinインスタンスのスライドデッキをフォローアップしたり

私の2カラット;）

@Arkanosisが書いたことにGitPubが目指していることのよう

このような仕様は、少なくともいくつかのGitWebサービス実装によって合意される必要があります。 あなたがそのようなソフトウェアの開発者であるならば、私たちの議論に参加して、声を上げてください。 単にあなたをワークグループに追加します。

@Arkanosisのコメントがディアスポラにも当てはまるかどうかはわかりませんが、もしそうなら、それは間違いなく私にとって役立つでしょう！ この機能を楽しみにしています！ :)

@Arkanosisのコメントがディアスポラにも当てはまるかどうかは

@KingDuckZ ：願っています！ ただし、前回チェックしたとき、DiasporaはActivityPubを実装していませんでした。 他のネットワーク（特にマストドン）と連携するために、そうすることを本当に望んでいます。 これにより、追加のメリットとして、ディアスポラやこの提案から得られるもの（GitPubなど）の統合がはるかに簡単になります。

確かに、ディアスポラフェデレーションプロトコル（webfingers + microformats +その他）を使用してディアスポラと直接フェデレーションすることは可能ですが、このプロトコルはActivityStreams / ActivityPubほどの牽引力を得ていないようです。

話題にとどまってください。 この問題は、リモートリポジトリからプルリクエストを開くことができることにのみ関連しています。 これを達成するために必要なのは、「レポとブランチ」の一般的な定式化だけです。

例はhttps://github.com/go-gitea/gitea.git#federated-prsです。

問題やコメントなどの他のデータのフェデレーションは、その範囲外です。 最初のステップとして、gitリポジトリにアカウントを作成せずにPRを作成できるはずだと思います。

@stevenrooseあなたが私に言及するなら：お詫びします、私はそれを＃1612に置くべきでした。 その間、他の誰かがそこでそれについて言及しました。

現在、ActivityPubベースのgitフェデレーションプロトコルを設計するためのワーキンググループ/プロジェクトが存在します。 https://github.com/git-federation/gitpub

興味があれば、彼らのメーリングリストに参加してください。

GitLabはそれを実装しています！
https://gitlab.com/gitlab-org/gitlab-ce/issues/40830
https://gitlab.com/groups/gitlab-org/-/epics/260

Niiii​​ce！

フェデレーションgitは素晴らしいでしょう。 gitリポジトリに数えられないアカウントを登録したくない...
フェデレーションPRと問題！ 👍

@pwFooこれを指定して実装するには時間がかかると思います。

gitリポジトリに数えられないアカウントを登録したくない...

それまでワンクリックで「GitHubでログイン」するオプションはありますか？

回避策になる可能性がありますが、将来的には、フェデレーションの問題/ PR、フェデレーションのソーシャルネットワーク（マストドン、プレローマ、ミスキーなど）を目標にする必要があります。

回避策になる可能性がありますが、将来的には、フェデレーションの問題/ PR、フェデレーションのソーシャルネットワーク（マストドン、プレローマ、ミスキーなど）を目標にする必要があります。

これのユースケースは何ですか？ ActivityPubプラットフォームとGitFedの間、またはここで構築されたソリューション間で情報を強制的に共有するためにgiteaを押しつぶすと、過剰設計につながる可能性があります。

@jalcineユースケースは、複数の異なるソフトウェアプロジェクトで作業する場合、これらのプロジェクトがホストされているすべてのプラットフォーム（GitHub、GitLab、または独自にホストされているGitea / GitLab /）でアカウントを作成して維持する必要がないことです。なんでもいい）。 理想的には、独自のリポジトリ（GitHub、GitLab、または独自のカスタムGitea）があり、独自のリポジトリから作業中のすべてのプロジェクトのPRを作成できます。

そうですが、私が返信した人は、マストドンを使用してGiteaにサインインすると言っていましたか？

私の場合、ホームサーバーにGiteaインスタンスがあります。 私のラズベリーパイと私のインターネット接続には限られたリソースがあります。 また、ボットがアカウントを作成できないようにして、空き時間の管理を減らしたいと考えています。

そのため、登録ページを無効にしました。 したがって、誰も私の公開リポジトリに問題を追加することはできません。

現在、人々から問題を取得する唯一の方法は、Githubのミラーリポジトリを使用することです。 しかし、その後、Giteaインスタンスを閉じることができます。

GiteaがGithubよりも優れている唯一の方法は、フェデレーションの問題とプルリクエスト（分散化の原則）をサポートすることです。

マストドンのようなソーシャルネットワークは別のトピックであり、持っているといいです。

しかし、フェデレーションの問題とプルリクエストは必須であるため、Nextcloud / Owncloudのように各インスタンスでのアカウント作成について心配する必要はありません。

@jalcine
「フェデレーションgitは素晴らしいでしょう。gitリポジトリに数え切れないほどのアカウントを登録したくない...
フェデレーションPRと問題！ 👍」

目標はGitHubまたはMastodonアカウントでログインしないことです...私は私の答えを引用しました。
目標は、1つのアカウント（理想的には自分のアカウント）を使用して、問題を開いたり、PRに返信したり、PRを開いたりすることです。

偽造されたメーリングリストで現在議論されているため、この問題をロックしました。すべての会話をそこでリダイレクトしてください。

詳細： https ：