Jeff King <p...@peff.net> writes:

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

Reply via email to