创建FETCH_HEAD的逻辑

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 ?!

- Basel Shishani

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中使用此功能的示例，该功能是作为shell脚本实现的：

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

- Cascabel

---

非常有趣。但是如果我执行“git merge FETCH_HEAD”，我就没有在两者之间做出选择的机会 - 那么我只能访问FETCH_HEAD的头部（因此它不会被覆盖，但实际上是这样吗），还是有其他规则。我知道我们现在正在接近实用性的边缘。 - Basel Shishani

是的，我不确定是否有工具可以让你循环遍历它的内容，或者你是否必须手动执行 - 大概主要是为了支持 git-pull。 - Cascabel

Answer 2

我喜欢把git fetch视为后端(plumbing)命令。

只需要一个远程主机参数的git fetch，已经是一个旧的、废弃的名称，等效于执行相同操作的git remote update。

需要两个或更多参数的git fetch形式，包含了其他所有操作的实际后端实现。如果你知道你在做什么，或者要编写脚本，那么它会偶尔很有用。例如，如果您想在正确获取分支之前检查它。

可以将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的单参数情况以及git remote update(更高级别)的需要。显然，这样做不太方便。

- FauxFaux

---

这在大多数情况下并不重要。我认为原帖作者已经知道如何使用git-fetch，并且只是想知道为什么它会将一个ref获取并存储到FETCH_HEAD中，然后再用另一个ref覆盖它。 - Cascabel

是的，我之前的理解是FETCH_HEAD就像一个原子指针。 - Basel Shishani