290

素晴らしくて単純な質問-「gitfetch」の関数は？の厳密なサブセットgit fetch --tagsですか？

つまり、私が走った場合git fetch --tags、すぐにすぐに走る理由はありgit fetchますか？

git pullとはどうgit pull --tagsですか？同じ状況？

4

6 に答える 6

197

注：git 1.9 / 2.0（2014年第1四半期）以降、オプションなしで同じコマンドラインによってフェッチされるものに加えてgit fetch --tagsタグをフェッチします。

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

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

詳細に：

Michael Haggerty（mhagger）によるcommitc5a84e9を参照してください。

以前は、fetchの" --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はより堅牢であるため、次のようになります。

2015年5月13日、Paul Tanによるコミット19d122bを参照してください。 （ 2015年5月22日、コミットcc77b99でJunio CHamanoによってマージされました）pyokagan
gitster

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

441ed41 （ " "：より良いメッセージでエラーアウト。、2007-12-28、Git 1.5.4+）以降、マージ候補が返されない場合は、別のエラーメッセージが 出力されます。git pull --tagsgit pull --tagsgit-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を使用すると、より高速になります。

Jeff King（）によるcommit 5827a03（2016年10月13日）を参照してください。（ Junio C Hamanoによってマージされました---コミット9fcd144 、2016年10月26日）peff
gitster

fetchhas_sha1_file：タグフォローに「quick」を使用

フォローしているブランチに関係のないタグが多数あるリモートからフェッチする場合、タグが指すオブジェクト（フェッチしない！）がリポジトリに存在するかどうかを確認するときに、多くのサイクルを浪費していました。慎重すぎる。

このパッチは、同時再パックで際どい可能性がある場合に、速度のために精度を犠牲にするためにHAS_SHA1_QUICKを使用するようにフェッチを教えています。

含まれているperfスクリプトの結果は次のとおりです。これは、上記と同様の状況を設定します。

Test            HEAD^               HEAD
----------------------------------------------------------
5550.4: fetch   11.21(10.42+0.78)   0.08(0.04+0.02) -99.3%

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

  1. クライアント側には、高価にするためのパックがたくさんありますreprepare_packed_git()（最も高価な部分は、現在2次式であるソートされていないリストで重複を見つけることです）。
  2. 自動フォローの候補である（つまり、クライアントが持っていない）サーバー側に多数のタグ参照が必要です。それぞれがパックディレクトリの再読み取りをトリガーします。
  3. 通常の状況では、クライアントはこれらのタグを自動フォローし、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四半期）は別の最適化を追加します。

鈴木正也（）によるcommit b7e2d8b（2019年9月15日）を参照してください。（ Junio C Hamanoによってマージされました---コミット1d8b0df、2019年10月7日）draftcode
gitster

fetch：oidset検索を高速化するために必要なOIDを保持するために使用

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

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

于 2013-12-16T10:10:00.723 に答える
134

注：この回答は、gitv1.8以前でのみ有効です。

これのほとんどは他の回答やコメントで述べられていますが、ここに簡潔な説明があります：

  • git fetchすべてのブランチヘッド（またはremote.fetch configオプションで指定されたすべて）、それらに必要なすべてのコミット、およびこれらのブランチから到達可能なすべてのタグをフェッチします。ほとんどの場合、すべてのタグはこの方法で到達可能です。
  • git fetch --tagsすべてのタグをフェッチし、それらに必要なすべてのコミットを取得します。フェッチされたタグから到達可能であっても、ブランチヘッドは更新されません。

概要：フェッチのみを使用して完全に最新の状態にしたい場合は、両方を実行する必要があります。

また、コマンドラインで入力するという意味でない限り、「2倍遅い」わけではありません。その場合、エイリアスによって問題が解決されます。2つの要求は異なる情報を要求しているため、2つの要求を行う際のオーバーヘッドは基本的にありません。

于 2009-07-30T17:53:00.313 に答える
52

私はこれに自分で答えるつもりです。

違いがあると判断しました。「gitfetch--tags」はすべてのタグを取り込む可能性がありますが、新しいコミットは取り込みません。

完全に「最新」にするためにこれを行う必要があることがわかりました。つまり、マージせずに「gitpull」を複製しました。

$ git fetch --tags
$ git fetch

2倍遅いので、これは残念です。「gitfetch」だけに、通常どおりに実行してすべてのタグを取り込むオプションがあった場合。

于 2009-07-30T05:58:33.633 に答える
32

ここでの一般的な問題は、git fetchをフェッチすること+refs/heads/*:refs/remotes/$remote/*です。これらのコミットのいずれかにタグがある場合、それらのタグもフェッチされます。ただし、リモートのどのブランチからも到達できないタグがある場合、それらはフェッチされません。

この--tagsオプションは、refspecをに切り替えます+refs/tags/*:refs/tags/*。あなたは両方をつかむように頼むことができます。git fetch次のコマンドを使用するだけで、必ず実行git fetch && git fetch -tできます。

git fetch origin "+refs/heads/*:refs/remotes/origin/*" "+refs/tags/*:refs/tags/*"

また、これをこのリポジトリのデフォルトにしたい場合は、デフォルトのフェッチに2番目のrefspecを追加できます。

git config --local --add remote.origin.fetch "+refs/tags/*:refs/tags/*"

これにより、このリモコンのに2fetch =行目が追加されます。.git/config

私はプロジェクトのためにこれを処理する方法を探してしばらく過ごしました。これが私が思いついたものです。

git fetch -fup origin "+refs/*:refs/*"

私の場合、これらの機能が必要でした

  • リモートからすべてのヘッドとタグを取得するため、refspecを使用しますrefs/*:refs/*
  • +refspecの前に、ローカルブランチとタグを非早送りで上書きします
  • 必要に応じて、現在チェックアウトされているブランチを上書きします-u
  • リモートに存在しないブランチとタグを削除します-p
  • そして、確認するように強制します-f
于 2013-02-18T22:57:52.940 に答える
11

ほとんどの場合、git fetch必要なことを実行する必要があります。つまり、「リモートリポジトリから新しいものを取得し、ローカルブランチにマージせずにローカルコピーに配置します」。 git fetch --tags新しいタグ以外は何も取得しないことを除いて、まさにそれを行います。

その意味で、git fetch --tagsは決してのスーパーセットではありませんgit fetch。実際、それは正反対です。

git pullもちろん、はのラッパーにすぎませんgit fetch <thisrefspec>; git merge。そもそも何をしているのかを理解するのに役立つという理由だけで、ジャンプする前に手動git fetchでingとingを行うことに慣れることをお勧めします。git mergegit pullgit pull

そうは言っても、関係はとまったく同じgit fetchです。 git pullのスーパーセットですgit pull --tags。

于 2009-07-30T12:19:33.023 に答える
3 
git fetch upstream --tags

正常に動作し、新しいタグのみを取得し、他のコードベースは取得しません。

于 2018-01-16T00:21:34.217 に答える