私はいくつかのケースで作成FETCH_HEADsの背後にあるロジックを理解していない

Question

作成FETCH_HEADsの背後にあるロジック - 例：

私は git fetchは、バックエンド（配管）コマンドであることをふりをしたいと

$ git --version 
git version 1.7.2.5 

$ git fetch aarep  
From ../aa 
* [new branch]  master  -> aarep/master 
* [new branch]  skin  -> aarep/skin 
## Fair enough, creating FETCH_HEADs here wouldn't help 


$ git fetch aarep master 
From ../aa 
* branch   master  -> FETCH_HEAD 
## Instead of creating a remote tracker, git creates a FETCH_HEAD. No problem. 

$ git fetch aarep master skin 
From ../aa 
* branch   master  -> FETCH_HEAD 
* branch   skin  -> FETCH_HEAD 
## What's the point of creating FETCH_HEADs here - only one would survive ?! 

Answer 1

最後の例の後にFETCH_HEADの内容を見てください。両方のリファレンスがあります。

b0d66b5110faaeb395610ba43b6eb70a18ab5e25  branch 'master' of git://git.kernel.org/pub/scm/git/git 
a9004c5cb2204cf950debab328e86de5eefb9da4  branch 'next' of git://git.kernel.org/pub/scm/git/git 

これは上書きされません。何が価値がある、ここでシェルスクリプトとして実装されているgit-pullでこの機能を使用するには、だのために

：

merge_head=$(sed -e '/ not-for-merge /d' \ 
    -e 's/ .*//' "$GIT_DIR"/FETCH_HEAD | \ 
    tr '\012' ' ') 

Answer 2

。

git fetchの1つの引数形式は、リモートのみをとるものであり、同じことを行う古い非推奨の名前git remote updateです。

リモートとブランチのリストを取る2つの引数形式は、実際のバックエンドの実装です。あなたがやっていることを知っているか、スクリプトを書いていることが時折役に立ちます。使用例は、適切にフェッチする前にブランチを検査したい場合です。

はgit fetch origin（git remote updateのような）を想像して基本的に行います。

git ls-remote originは枝がoriginで使用可能なものを見つけるために。その後、見つかった各ブランチのために（つまりは、「すべてのブランチ」にフェッチ仕様、デフォルトと一致する）：

1. git fetch origin thatbranchは、低レベルのフェッチを行うこと。
2. git branch -f origin/thatbranch FETCH_HEAD "リモートトラッキングブランチ"（リモートブランチのローカルコピー）をそのFETCH_HEADに移動するには、

あなたはgit fetch年代1引数のケースについて、およびgit remote update（さらに高いレベル）の必要性を取り除く、手でこれを行うのは自由です。明らかに、これはあまり便利ではないでしょう。