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

Felipe Contreras <felipe.contreras@gmail.com> writes:

To those who fear running "git pull", the following has worked as a quick way to "preview" what they would be getting.

	git fetch
        git log ..FETCH_HEAD

and then they can "git merge FETCH_HEAD" to conclude it, or run a "git pull" for real. We teach the more explicit form to end users in our tutorial, but it shows the explicit form only because we want to illustrate what goes on. Over time we added support to "git fetch" (and "git pull") to make it possible for users to type less when the remote and branch involved are obvious, but we carefully avoided breaking this expectation.

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

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.