Drew Northup <n1xim.email@xxxxxxxxx> writes: > On Mon, Oct 8, 2012 at 7:33 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> Junio C Hamano <gitster@xxxxxxxxx> writes: >> >> I personally do not think the downside of breaking backward >> compatibility is too bad. If we do this only when we already are >> configured to keep remote tracking branch for branch $branch from >> remote $from (it has to be given as a nickname, not URL that happens >> to have an entry in the configuration), then a promiscuous fetch >> that grabs from a URL (or a nickname that is configured not to keep >> tracking branches) will not change any behaviour, and when you want >> to keep your remote tracking branch intact while doing one-shot >> fetch for whatever reason, you can say "git fetch $from $branch:" to >> explicitly decline copying. > > How are we supposed to remember those are different? > > "git fetch $from $branch..." > VS > "git fetch $from $branch:" I do not know what you meant by the three dots, but you are supposed to know what you meant by $branch... whatever it is. It is what you wrote, not I did ;-) Let me clarify what is in the message you are responding to. git fetch $from $branch (no colon in $branch part anywhere) traditionally meant a short-hand of saying git fetch $from $branch: I.e. "fetch $branch and store in FETCH_HEAD but not anywhere else". The hypothesized change is to make it a short-hand of saying git fetch $from $branch:refs/remotes/$from/$branch when "git fetch $from" is already configured to store the result there. Without [remote "$from"] fetch = refs/heads/*:refs/remotes/$from/* configured, it will still mean "git fetch $from $branch:". And for the record, I am *not* enthused about such a change. I am only saying that, seeing that many new people seem to wish the command behaved that way, such a change would not hurt existing users too much. Switching the meaning of shorthand (i.e. a piece of refspec that does not have any colon) from "just fetch but do not store" from "fetch and store in the remote tracking ref if it is configured to do so without command override" is still a backward incompatible change. > I strongly prefer EXPLICITLY setting tracking than expecting some > extreme syntactic nuance to quietly do it for me now and confuse the > heck out of me later. This is not about your preference. This is about what happens when you say something on the command line to override your explicit setting you have in $GIT_DIR/config [remote "$from"] fetch = ... -- 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