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