Re: Your branch and 'origin/master' have diverged

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 15, 2012, 17:30 UTC
Message-ID: <7vfw7o6p1g.fsf@alter.siamese.dyndns.org>
In-Reply-To: <87sjbo63pl.fsf@thomas.inf.ethz.ch>

Thomas Rast <trast@student.ethz.ch> writes:

Show 17 quoted lines

> Junio C Hamano <gitster@pobox.com> writes:
>
>> Thomas Rast <trast@student.ethz.ch> writes:
>>
>>> In some sense this is a really bad case of wrong UI design, because we
>>> (this happens on #git a lot) have to teach users not to use the command
>>> so they won't trip over this problem.  It would be better to fix the
>>> real issue instead.  IIRC it was even on the 1.8.0 wishlist...
>>
>> Is it?
>>
>> There already is a way to ask it to update the single tracking
>> branch while fetching; "git fetch origin master" that
>> unconditionally updates refs/remotes/origin/master without a way to
>> tell it not to do so will be a grave usability regression.
>
> Grave?  Do you have any data/use-cases to back that up with?

When I get a pull request from say Eric, I would:

	git fetch git-svn master
        git show-branch remotes/git-svn/master FETCH_HEAD

to see what happened since the last pull request on the other side. He may have rebased (which is not necessarily a crime), or I may see more commits in the output than what he lists in the request message (which may indicate I may have missed an earlier pull request from him).

Such a sanity check will stop working if the first "fetch" updated my remotes/git-svn/master. I would have to enable reflog for tracking branch and do something like this:

	git show-branch remotes/git-svn/master@{1} remotes/git-svn/master

So I was correct in saying that without an easy escape hatch, such a change would be a regression.

But I think I (and others) could just train fingers to do

	git fetch git-svn master:

as a workaround.

Updating Documentation/pull-fetch-param.txt would be a bear, though. The documentation is stale in that it was written in the days back when .git/remotes/ was the primary way to configure remotes, and was not adjusted to use the termilology used in the [remote "where"] section of the .git/config file (notice a mention of "'Pull: ' lines" there), so it needs cosmetic adjustment anyway, but the semantics it spells is still up to date. The current rule is very simple and understandable. You either say from the command line exactly what should happen (refspec without colon is the same as the refspec with colon at the end, meaning "do not track"; if you want to track, you write what to update with the fetch), or we use the configured refspec (which again spells what should happen).

The updated rule would be more complex. If a remote nickname is used, and a refspec given from the command line is without colon, a new special rule overrides the current behaviour and tries to match with a configured refspec. You would need to desribe what happens in that case.