Re: Ensimag students projects, version 2013

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 15, 2013, 14:53 UTC
Message-ID: <7v1uab26bn.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20130415140513.GA16154@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 22 quoted lines

> On Mon, Apr 15, 2013 at 11:24:21AM +0200, Matthieu Moy wrote:
>
>> > * git pull --set-upstream
>> >
>> >   This is vaguely related to another itch that nobody has bothered to
>> >   fix: 'git fetch origin foo' should really update origin/foo.  This has
>> >   been discussed on the list a few times already:
>> >
>> >     http://thread.gmane.org/gmane.comp.version-control.git/192252
>> >     http://thread.gmane.org/gmane.comp.version-control.git/165720/focus=165758
>> >
>> >   which by the way would be a *great* thing to fix, hint hint ;-)  and
>> >   since Peff already posted a POC patch in the first thread, it's
>> >   probably not that hard.  (Peff?)
>> 
>> My understanding is that this would be technically easy to fix, but a
>> migration plan is needed, which isn't easy for a one-shot, one-month
>> contribution.
>
> Yes. The concept isn't that hard, but the question was one of whether it
> would break some obscure workflows. But I don't remember all of the
> details; I think I gave some examples in past threads.

I think the one Thomas lists in $gmane/165758 is the one.

It has been the way for users to make sure that origin/master stays put to explicitly tell Git not to update the remote tracking branch using a refspec without colon, so that they can do

	git fetch origin master
	git log origin/master..FETCH_HEAD

(or its three-dot variant) to gauge the progress of the other side since the last time the user observed.

Personally I doubt this trick is so relevant these days, not just because we can look at reflog of origin/master. The user could just do

	old=$(git rev-parse origin/master)
        git fetch origin master
        git log $old..FETCH_HEAD

even with a modified Git that updates the remote tracking branches without a storing refspec.

The primary reason why I do not think this is relevant these days is because the original premise "remote tracking branches keep what the last 'git fetch' observed" has already been broken for a long time. The users are better off thinking that the remote tracking branches can be updated any time (not just the last 'git fetch') when Git observes (or could observe) the state of the remote without being told explicitly with today's "pretend as if we fetched immediately after we push" behaviour.