> I have a feeling that "git checkout -b" and "git checkout -B" > should be taught to explicitly use "git branch --no-track" and > "git branch --track" to create a new branch (currently it does > not even use "git branch" as far as I can tell). With your > patch, I suspect that you have to say "git branch topic > origin/topic" and then "git checkout topic", which means you > made the three-step process into two steps, but you could have > made it into one step. Well, yes, the next part would have been to patch git-checkout. But this one is already proving to be complicated enough. :-) > I'll send out an untested patch to > git-checkout so that you can try it out in a separate message. I saw it. I tested your patch and it seems to work. > - (micronit) Is it true that both strlen() tests are about long > *branch* names? If you consider something like "origin/next" to be a branch name, yes. > - (moderately serious) The code blindly trusts that > "refs/remotes/foo/bar" tracks "refs/heads/bar" from remote > named "foo", which is a bit disturbing. With the default > configuration git-clone and git-remote creates, it always is > the case, but I suspect you might want to at least verify > that assumption (the user can have different settings in the > config), if not figuring them out by reading the existing > configuration yourself. Ouch. Absolutely right, but this means I will prepare the patch later then. >> + else if (dwim_ref(start_name, strlen(start_name), sha1, &real_ref)) >> + remote = !prefixcmp(real_ref, "refs/remotes/"); > > - (pure question) What happens if dwim_ref() returns more than one? Then, real_ref is the one matching sha1. Considering your other objection about the naming of the variable, what about enabling/disabling the tracking using remote.REMOTENAME.tracklocalsubbranches? Paolo - 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