Re: [PATCH] write first for-merge ref to FETCH_HEAD first

[Junio C Hamano <gitster@pobox.com>]

Joey Hess <joey@kitenet.net> writes:

> The FETCH_HEAD refname is supposed to refer to the ref that was fetched
> and should be merged. However all fetched refs are written to
> .git/FETCH_HEAD in an arbitrary order, and resolve_ref_unsafe simply
> takes the first ref as the FETCH_HEAD, which is often the wrong one,
> when other branches were also fetched.
>
> The solution is to write the for-merge ref(s) to FETCH_HEAD first.
> Then, unless --append is used, the FETCH_HEAD refname behaves as intended.
> If the user uses --append, they presumably are doing so in order to
> preserve the old FETCH_HEAD.
>
> Also included a fix to documentation that assumes FETCH_HEAD contains
> only a single ref.

That "single ref" assumption is perfectly fine for the part of the
documentation you patched, actually. The "fetch" command-line the example
shows explicitly fetches a single ref.

It is a good idea to use rev-parse anyway, so the patch itself is good. A
potential problem of that example (I haven't re-tried these examples for
eons since they were written) comes from the fact that FETCH_HEAD contains
not just the object name of what we fetched, but also other information to
describe what happened to that fetched object.

> ---

Sign-off?

>  Documentation/git-read-tree.txt |    2 +-
>  builtin/fetch.c                 |  158 +++++++++++++++++++++------------------
>  2 files changed, 85 insertions(+), 75 deletions(-)