On Fri, May 17, 2013 at 1:30 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > 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, 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 -- 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