From: Philip Oakley <philipoakley@iee.org>
Date: Sat, 18 May 2013 13:12:05 GMT
Subject: Re: [PATCH 1/3] fetch: add --allow-local option
Message-ID: <E74470E4201142788D36127322130401@PhilipOakley>
In-Reply-To: <7vtxm1xxvd.fsf@alter.siamese.dyndns.org>

From: "Junio C Hamano" <gitster@pobox.com>
Sent: Friday, May 17, 2013 7:30 PM
Subject: Re: [PATCH 1/3] fetch: add --allow-local option

[...]

> So when "the user" is running "git fetch" on "mywork" branch that
> happens to be forked from a local "master", i.e. her configuration
> is set as
>
> [branch "mywork"]
>        remote = .
>                merge = refs/heads/master
>

Was the '.' example illustrative rather than exact. I see no case of 
using '.' in my configs. Or am I completely missing the point? (e.g. 
that the use of '.' an example of possible future usage)?


> we still need to have FETCH_HEAD updated to point at what we would
> be merging if she did a "git pull".  It may be OK to additionally
> fetch objects from 'origin' and update the remote tracking branches
> associated with 'origin', but anything from 'origin' should not
> contaminate what results in FETCH_HEAD---it should record whatever
> we record when we did fetch refs/heads/master from '.'.
>
> As I said in the very beginning, it was a mistake for me to suggest
> adding a special case behaviour for '.' remote in the first place.
> It breaks a long-standing expectation and workflow built around it.
>
> So sorry for wasting our time, and consider this as a misguided
> excursion.
> --

Philip