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

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 27, 2011, 18:44 UTC
Message-ID: <7v1urp97mp.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20111226161656.GB29582@gnu.kitenet.net>

Joey Hess <joey@kitenet.net> writes:

Show 13 quoted lines

> 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(-)