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

Joey Hess [off-list ref] 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(-)