Re: FETCH_HEAD question

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 17, 2009, 07:18 UTC
Message-ID: <7vr61x8ra4.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <76718490902162221i31e02052j48c9f620a2d47985@mail.gmail.com>

Jay Soffian <jaysoffian@gmail.com> writes:

Show 5 quoted lines

> 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. :-(

Your "git merge FETCH_HEAD" after fetching random set of refs by the default wildcard refspec in .git/config made me suspect you aren't.

Show 7 quoted lines

>>        $ git fetch git://repo.or.cz/his.git for-linus
>>        $ git log -p ..FETCH_HEAD ;# to inspect
>>        $ git merge FETCH_HEAD
>> ...
> 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.

Because it is designed to handle a lot more general case of fetching all remote branches into your remote tracking branches with wildcard refspecs, and most of the entries need to be marked with not-for-merge marker. If you left only the for-merge branches, you would not have any sane way to learn what refs were fetched after you said "git fetch" (and no, looking at timestamp of files in .git/refs/remotes/origin/ is not a sensible answer).