なぜgit fetch originの動作が+ refs/heads/master：refs/remotes/origin/mymasterとgit fetch origin master：mymasterが違うのですか？

Question

なぜ

git fetch origin +refs/heads/master:refs/remotes/origin/mymaster 

と

git fetch origin master:mymaster 

の動作が違うのですか？私の観察で

git fetch origin +refs/heads/master:refs/remotes/origin/mymaster 

の場合には、それはリモート追跡ブランチ「mymaster」を作成していました。

git fetch origin master:mymaster 

の他の場合には、それはローカルブランチ "mymaster" を作成していました。

Answer 1

井戸git fetchはローカル参照を早送りし、存在しない場合は作成します。だから、：

git fetch origin master:mymaster 

が存在しない場合は、ローカルブランチmymasterを作成し、それが存在しない場合は

git fetch origin +refs/heads/master:refs/remotes/origin/mymaster 

がローカルのブランチremotes/origin/mymasterを作成します。

src:dst（srcはリモート、dstローカル）の構文があります。

Answer 2

gitrevisionsのマニュアルページ（git help revisionsを実行）を読み、改訂の仕様「<refname>」を探してください。ここにその文書の抜粋があります：

<refname>master,heads/master,refs/heads/master

記号的な参照名。例えば。 masterは、通常、refs/heads/masterによって参照されるコミットオブジェクト を意味します。 heads/masterと tags/masterの両方がある場合は、 heads/masterと明示的に言ってGitに指示してください。 、<refname>は以下のルールで最初に一致 を取ることによって明確化されると、あいまいな：

1. $GIT_DIR/<refname>が存在する場合、つまり、あなたは何を意味するか （これは、、MERGE_HEAD ORIG_HEADFETCH_HEADだけHEADために通常に有用ですおよびCHERRY_PICK_HEAD）;
2. もしそうであればrefs/<refname>;
3. もしそうであればrefs/tags/<refname>;
4. もしそうなら、refs/heads/<refname>;
5. もしそうなら、refs/remotes/<refname>;
6. それ以外の場合はrefs/remotes/<refname>/HEADが存在します。

それで、あなたの実験で観察すると、相対 REFの名前だったのGitの観点から、名前REFターゲットとして飾り気のないmybranchを使用しているときということであるので、Gitは使用これを解決するための優先順位のルールを作成し、refs/heads/mymasterに解決しました。

refs/remotes/origin/mymasterを使用した場合、Gitにの絶対名というref nameが指定されているため、解決するものは何もなく、Gitはそれを直接使用しました。

重要なポイント：名前にスラッシュを含むローカルブランチを持つことはまったく問題ありません。また、refs/...アンカーなしで指定した場合でも相対的な関係になります。つまり、git branch foo/barを実行し、後でgit log foo/barと呼ぶと、Gitは上記の規則を使用してfoo/barを絶対参照名に変換します（そして最終的にはrefs/heads/foo/barになります）。