「git fetch --tags」には「git fetch」が含まれますか? 質問する

Question

注: から始まるgit 1.9/2.0 (2014年第1四半期)は、オプションなしの同じコマンドラインで取得されるものに加えて、git fetch --tagsタグも取得します。

タグのみを取得するには:

git fetch <remote> 'refs/tags/*:refs/tags/*'

詳細に：

見るコミット c5a84e9によるマイケル・ハガーティ（mhagger）:

以前は、フェッチの「--tags」オプションはrefspecを指定することと同等であると考えられていました。
refs/tags/*:refs/tags/*
コマンドラインでは、特に、remote.<name>.refspec構成が無視される原因となっていました。

しかし、他の参照も取得せずにタグを取得することはあまり有用ではありません。一方、他の参照に加えてタグを取得できることは非常に有用です。したがって、後者を実行するにはこのオプションのセマンティクスを変更します。

ユーザーがタグのみを取得したい場合でも、明示的な refspec を指定することも可能です。
git fetch <remote> 'refs/tags/*:refs/tags/*'
1.8.0.3 より前のドキュメントでは、「fetch --tags」の動作のこの側面について曖昧であったことに注意してください。
コミット f0cb2f1(2012-12-14)fetch --tagsドキュメントを古い動作に合わせました。
このコミットはドキュメントを新しい動作に合わせるように変更します (Documentation/fetch-options.txt）。

取得される他のものに加えて、すべてのタグをリモートから取得するように要求します。

Git 2.5 (2015 年第 2 四半期) ではgit pull --tagsさらに堅牢になりました。

見るコミット 19d122bによるポール・タン（pyokagan）2015年5月13日
^{（合併）ジュニオ・C・ハマノ -- gitster--でコミット cc77b99、2015年5月22日）}

pull:--tagsマージ候補がない場合のエラーを削除

以来441ed41(" git pull --tags": より適切なメッセージでエラーを出力します。、2007-12-28、Git 1.5.4+) は、マージ候補が返されなかったgit pull --tags場合、異なるエラーメッセージを出力します。git-fetch
It doesn't make sense to pull all tags; you probably meant:
      git fetch --tags
これは、その時点では、git-fetch --tags設定された refspec が上書きされ、マージ候補がなくなるためです。そのため、混乱を防ぐためにエラーメッセージが導入されました。

しかし、c5a84e9( fetch --tags:他のものに加えてタグをフェッチ、2013-10-30、Git 1.9.0+) は、git fetch --tags設定された refspec に加えてタグをフェッチします。
したがって、マージ候補がない状況が発生した場合、それはが設定されたためではありません--tags。そのため、この特別なエラーメッセージは無関係になりました。

混乱を避けるために、このエラーメッセージを削除してください。

Git 2.11+ (2016 年第 4 四半期) ではgit fetchさらに速くなります。

見るコミット 5827a03(2016年10月13日)ジェフ・キング（peff）^（合併者：
^{ジュニオ・C・ハマノ -- gitster--でコミット 9fcd144、2016年10月26日）}

fetch: 「クイック」を使用するhas_sha1_fileタグフォロー用

フォローしているブランチとは無関係なタグが多数あるリモートからフェッチする場合、タグによって指されているオブジェクト (フェッチしないオブジェクト) がリポジトリ内に存在するかどうかを慎重にチェックしすぎて、非常に多くのサイクルを無駄にしていました。

このパッチは、同時再パックで競合が発生する可能性がある場合に、速度を優先して精度を犠牲にして HAS_SHA1_QUICK を使用するように fetch に指示します。

以下は、上記と同様の状況を設定する、付属の perf スクリプトの結果です。
Test            HEAD^               HEAD
----------------------------------------------------------
5550.4: fetch   11.21(10.42+0.78)   0.08(0.04+0.02) -99.3%

これは、次の状況にのみ適用されます。

クライアント側にはコストがかかるパックがたくさんありますreprepare_packed_git()(最もコストがかかる部分は、現在 2 次であるソートされていないリスト内の重複を見つけることです)。

サーバー側には、自動フォローの候補となる (つまり、クライアントが持っていない) 多数のタグ参照が必要です。それぞれがパックディレクトリの再読み取りをトリガーします。

通常の状況では、クライアントはそれらのタグを自動的に追跡し、1 回の大規模なフェッチの後、(2) は当てはまらなくなります。
ただし、それらのタグが、クライアントがフェッチするものとは切り離された履歴を指している場合、自動的に追跡されることはなく、それらの候補はすべてのフェッチに影響を与えます。

Git 2.21（2019年2月）では、設定はデフォルトremote.origin.fetchではありません（'+refs/heads/*:refs/remotes/origin/*'）

fatal: multiple updates for ref 'refs/tags/v1.0.0' not allowed

Git 2.24 (2019 年第 4 四半期) では、さらに別の最適化が追加されました。

見るコミット b7e2d8b(2019年9月15日)鈴木正也 ( draftcode)^（合併者：
^{ジュニオ・C・ハマノ -- gitster--でコミット 1d8b0df、2019年10月7日）}

fetch:oidset高速検索のために必要なOIDを保持するために使用します

実行中git fetch、クライアントは、アドバタイズされたタグの OID がフェッチ要求の要求 OID セットにすでに含まれているかどうかを確認します。
このチェックは線形スキャンで実行されます。
参照が多数あるリポジトリの場合、このスキャンを繰り返すと 15 分以上かかります。

これを高速化するには、oid_set他の参照の OID 用のを作成します。

Answer 1