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

On Fri, May 17, 2013 at 1:30 PM, Junio C Hamano [off-list ref] wrote:

Felipe Contreras [off-list ref] writes:

quoted

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
typical users.

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
excursion.

It doesn't matter, the problem that 'git fetch' does something totally
and completely uses is still there.

-- 
Felipe Contreras