Question

我不理解在某些情况下创建FETCH_HEAD的逻辑 - 例如：

$ 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

我喜欢假装git fetch是一个后端（管道）命令。

git fetch的一个参数形式，它只是一个遥控器，是git remote update的一个旧的，已弃用的名称，它做同样的事情。

带有远程和分支列表的二加参数形式是其他所有内容的实际后端实现。如果您知道自己在做什么或者编写脚本，那么它就会被曝光，因为它偶尔会有用。一个示例用法是，如果要在正确获取分支之前检查分支。

想象git fetch origin（就像git remote update）基本上做的那样：

git ls-remote origin找出origin上可用的分支。然后，对于找到的每个分支（与获取规范匹配，默认为“所有分支”）：

git fetch origin thatbranch，进行低级抓取。
git branch -f origin/thatbranch FETCH_HEAD将您的“远程跟踪分支”（您的远程分支的本地副本）移动到FETCH_HEAD。

您可以手动执行此操作，无需git fetch的单参数案例，也可以git remote update（更高级别）。显然这不太方便。

Answer 2

在上一个例子之后看一下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中使用了这个功能，它是作为shell脚本实现的：

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

创建FETCH_HEADs背后的逻辑

2 个答案: