一個不錯的簡單問題-“ git fetch”的函數是否是的嚴格子集git fetch --tags？即是說，如果我跑步git fetch --tags，是否有理由立即直接跑步git fetch？怎么樣git pull和git pull --tags？同樣的情況？
3 回答
慕田峪7331174
TA貢獻1828條經驗 獲得超13個贊
注意：從git 1.9 / 2.0（Q1 2014）開始，除了在同一命令行中不帶選項的情況下，還將git fetch --tags獲取標簽。
見提交c5a84e9由邁克爾·哈格蒂（mhagger） ：
以前，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年第二季度）git pull --tags更強大：
參見Paul Tan（）提交的commit 19d122b，2015年5月13日。（由Junio C Hamano合并--在cc77b99提交中，2015年5月22日）pyokagan
gitster
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年第四季度）git fetch更快。
參見Jeff King（）提交5827a03（2016年10月13日）。（由Junio C Hamano合并--在commit 9fcd144中，2016年10月26日）peff
gitster
fetch：使用“快速” has_sha1_file進行標記跟蹤
當從具有很多與分支無關的標簽的遠程進行提取時，我們通常會在檢查存儲庫中是否存在由標簽指向的對象（我們不會提?。。r浪費了太多的時間。太小心了
此修補程序告訴fetch使用HAS_SHA1_QUICK犧牲準確性以提高速度，以防我們可能因同時重新打包而感到厭倦。
以下是所包含的perf腳本的結果，該腳本設置了與上述情況類似的情況：
Test HEAD^ HEAD
----------------------------------------------------------
5550.4: fetch 11.21(10.42+0.78) 0.08(0.04+0.02) -99.3%
這僅適用于以下情況：
您在客戶端有很多包裝，reprepare_packed_git()價格昂貴（最昂貴的部分是在未排序的列表中查找重復項，該列表目前是二次的）。
您需要在服務器端有大量的標記引用，這些標記引用可以自動跟蹤（即客戶端沒有）。每一個都會觸發對pack目錄的重新讀取。
在正常情況下，客戶端會自動關注這些標簽，并且在進行一次大抓取后，（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年第四季度）增加了另一個優化。
請參閱Masaya Suzuki（）的commit b7e2d8b（2019年9月15日）。（由Junio C Hamano合并--在commit 1d8b0df中，2019年10月7日）draftcode
gitster
fetch：用于oidset保留想要的OID以便更快地查找
在期間git fetch，客戶端檢查廣告標記的OID是否已經在獲取請求的OID集中。
該檢查是在線性掃描中完成的。
對于具有大量引用的存儲庫，重復此掃描需要15分鐘以上。
為了加快速度，請oid_set為其他裁判的OID 創建一個。
慕勒3428872
TA貢獻1848條經驗 獲得超6個贊
注意：此答案僅對git v1.8及更早版本有效。
在其他答案和評論中已經說了大部分，但這是一個簡潔的解釋：
git fetch獲取所有分支頭（或所有由remote.fetch config選項指定的分支頭），它們所需的所有提交以及從這些分支可訪問的所有標記。在大多數情況下，所有標簽都可以通過這種方式訪問。git fetch --tags獲取所有標簽，并完成所有必需的提交。即使從提取的標簽可以到達分支頭，它也不會更新。
簡介：如果您真的想完全保持最新，僅使用訪存，則必須同時進行。
除非您是在命令行中輸入，否則它也不會“慢兩倍”，在這種情況下，別名可以解決您的問題。發出兩個請求基本上沒有開銷，因為它們要求的是不同的信息。
qq_笑_17
TA貢獻1818條經驗 獲得超7個贊
我將自己回答。
我確定有區別?！?git fetch --tags”可能會引入所有標簽，但不會帶來任何新的提交！
事實證明，這樣做必須完全“最新”，即在沒有合并的情況下復制了“ git pull”：
$ git fetch --tags
$ git fetch
真可惜，因為速度慢了兩倍。如果只有“ git fetch”可以選擇執行其通常的操作并引入所有標簽
- 3 回答
- 0 關注
- 1783 瀏覽
添加回答
舉報
0/150
提交
取消