Re: Your branch and 'origin/master' have diverged
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Aug 16, 2012, 17:57 UTC
- Message-ID
- <7vsjbm1zz1.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <20120816162417.GD2853@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 37 quoted lines
> 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.