From: Jay Soffian <jaysoffian@gmail.com>
Date: Tue, 17 Feb 2009 06:21:00 GMT
Subject: Re: FETCH_HEAD question
Message-ID: <76718490902162221i31e02052j48c9f620a2d47985@mail.gmail.com>
In-Reply-To: <7veixxaale.fsf@gitster.siamese.dyndns.org>

On Tue, Feb 17, 2009 at 12:36 AM, Junio C Hamano <gitster@pobox.com> wrote:
> [... explanation of how git pull and git fetch communicate via FETCH_HEAD...]

I'm aware of all that, and I apologize for not making that clear,
since I made you do lots of extra typing. :-(

> Having said that, being able to directly use FETCH_HEAD as an extended
> SHA-1 is often useful when somebody asks an integrator to pull one-shot
> with git-request-pull.  Upon receiving such a request, the integrator can
> say:
>
>        $ git fetch git://repo.or.cz/his.git for-linus
>        $ git log -p ..FETCH_HEAD ;# to inspect
>        $ git merge FETCH_HEAD
>
> to take advantage of the fact that the commit object name that appears at
> the beginning of resulting FETCH_HEAD file is actually the commit we would
> want, because by definition FETCH_HEAD records only one commit when we are
> fetching only one branch.

That makes sense, but I was confused why git merge goes through the
trouble of stripping out the not-for-merge tag which in the above use
case wouldn't be there.

j.