Joey Hess <joey@xxxxxxxxxxx> 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(-) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html