Re: [PATCH 1/5] fetch doc: update introductory part for clarity

From: Junio C Hamano <gitster@pobox.com>
Date: May 30, 2014, 21:27 UTC
Message-ID: <xmqq61kn7yaj.fsf@gitster.dls.corp.google.com>
In-Reply-To: <5388D857.7010705@xiplink.com>

Marc Branchaud <marcnarc@xiplink.com> writes:

Show 5 quoted lines

> The docs say that all the fetched refs are written to FETCH_HEAD (perhaps a
> more accurate name would have been FETCH_HEADS?).  If that's truly the case,
> it seems weird to use FETCH_HEAD in log and merge commands.  (My FETCH_HEAD
> file currently has 1434 lines in it -- what does that mean, and what does it
> imply for those log and merge commands?)

The "fetch" that was run by "pull" would have arranged the single remote ref that your "pull" merged to your then-current branch to the very beginning of FETCH_HEAD, so "git log FETCH_HEAD" would show the line of development from that ref, and "git merge FETCH_HEAD" would also merge what your "pull" would have merged.

> Perhaps FETCH_HEAD shouldn't be mentioned at all in the introductory part of
> fetch's man page.

A possible downside is that unreasonable people can use the lack of mention of FETCH_HEAD as an excuse to start making noises about removing the feature.

Also, a natural way to peek into somebody else's history without making a permanent damage to your own repository, is:

    $ git fetch $repository_of_marc master && git log FETCH_HEAD

As such a one-shot fetch from a random place does not use (and does not want to use) any remote-tracking branch, knowing that FETCH_HEAD is available for such a purpose would help people who want to script such a thing.