Re: [PATCH 1/3] fetch: add --allow-local option

From: "Junio C Hamano" <redacted>
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