Felipe Contreras <felipe.contreras@xxxxxxxxx> writes:
> This is irrelevant, it's an implementation detail of 'git pull'. *THE
> USER* is not running 'git fetch .'
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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html