From: Junio C Hamano <gitster@pobox.com>
Date: Thu, 16 Aug 2012 17:57:54 GMT
Subject: Re: Your branch and 'origin/master' have diverged
Message-ID: <7vsjbm1zz1.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20120816162417.GD2853@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

> On Wed, Aug 15, 2012 at 12:22:28PM -0700, Junio C Hamano wrote:
>
>> > 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.
>> 
>> It would be something like this.
>> 
>> When you tell "git fetch" to fetch one or more refs from a
>> configured remote by explicitly listing them on the command line,
>> e.g.
>> 
>>     git fetch <remote> <name>...
>> 
>> each <name>... goes through the following process:
>>
>>     - The <name> is turned into the full ref at the remote that
>>       starts from refs/ form by applying the usual fetch dwimmery
>>       (if <name> is a name of a branch, "refs/heads/<name>" would
>>       likely to be the one that is fetched).
>> 
>>     - Then, configured fetch refspecs for <remote> is looked up from
>>       remote.<remote>.fetch configuration variable(s), or "Pull: "
>>       line(s) of .git/remotes/<remote> file.
>> 
>>     - If the LHS of a refspec found in the previous step matches the
>>       full ref we computed in the first step, then the ref at the
>>       RHS of the refspec (i.e. remote tracking branch), if any, is
>>       updated.
>> 
>> If there is no configured refspecs that match the name given from
>> the command line, no remote tracking ref is updated.
>
> That is almost exactly what my patch does, except I am not sure that it
> respects the "without a colon" bit from your first message.

Yeah, I forgot to repeat it in this message, but the above
three-bullet list needs the 0-th item

 - If <name> has already colon in it, following special case rules
   do not apply.

in front of it.

Even though I suspect the updated behaviour may be more useful for
casual users (while making the semantics a bit more difficult to
explain, like the above documentation update), it is a major
regression to existing users if it closes the last escape hatch, so
I guess with your patch we are almost there but not quite there yet.