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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html