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.


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