From: Jeff King <peff@peff.net>
Date: Thu, 16 Aug 2012 16:24:18 GMT
Subject: Re: Your branch and 'origin/master' have diverged
Message-ID: <20120816162417.GD2853@sigill.intra.peff.net>
In-Reply-To: <7va9xw55aj.fsf@alter.siamese.dyndns.org>

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. In other
words, any time it sees that we have fetched a ref from a particular
remote, it applies the mapping from the config and adds the result to
the list of refs to be updated.

-Peff