On Fri, May 17, 2013 at 1:30 PM, Junio C Hamano <gits...@pobox.com> wrote:
> Felipe Contreras <felipe.contre...@gmail.com> 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,
That "tutorial" is mostly irrelevant; it has not been properly updated
in years, and it doesn't do it's job properly.
Nowadays most people use the Pro Git book, which doesn't mention
FETCH_HEAD even once. And why would it? It's not a useful concept for
> 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".
No, we don't need that. That is only needed by 'git pull', and in
fact, it should be possible to reimplement 'git pull' so that it skips
FETCH_HEAD when the remote is local.
These are mere implementation details.
> 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.
The fact that it's "long-standing" doesn't mean it's sane.
> So sorry for wasting our time, and consider this as a misguided
It doesn't matter, the problem that 'git fetch' does something totally
and completely uses is still there.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html