From: Jay Soffian <jaysoffian@gmail.com>
Date: Tue, 17 Feb 2009 07:41:15 GMT
Subject: Re: FETCH_HEAD question
Message-ID: <76718490902162341y2f122427i470c77d3915ff554@mail.gmail.com>
In-Reply-To: <7vr61x8ra4.fsf@gitster.siamese.dyndns.org>

On Tue, Feb 17, 2009 at 2:18 AM, Junio C Hamano <gitster@pobox.com> wrote:
> 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).

We are talking past each other.

I understand the not-for-merge marker, why git fetch puts it there,
and how it is used by git pull.

I was asking why "git merge FETCH_HEAD" is useful, and you gave an
example of fetching a *single* branch using "git fetch <url>
<branch>". But in that case, as you said, git fetch does *not* leave a
"not-for-merge" marker, since only one branch was fetched.

So then, why does "git merge FETCH_HEAD" bother to strip out a
not-for-merge marker that wouldn't be there?

I can only guess there is a use case where one fetches multiple
branches and then uses "git merge FETCH_HEAD".

j.