Jeff King <peff@xxxxxxxx> 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. -- 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