On Thu, Mar 12, 2009 at 04:16:09PM +0000, John Tapsell wrote: > I was thinking more along the lines of checking if it begins with > remotes/, origin/, tags/, stash/, bisect/ and blacklisting these. > > Can anyone suggest a reason that you really might want to create a > branch called origin/something ? The name "origin" is simply convention. So if you are thinking about blacklisting "origin/*", then it is certainly possible to have a false positive (although as you note, it is unlikely). But what is worse is that it is very likely for you to have a false negative if you use a different remote name (and people often do if they have multiple remotes). For example, in one of my projects where I do integration, "origin" is my own public repo, and I have a remote pointing to the public repo of a number of other developers from whom I pull. So I would encounter the same error by doing: git checkout -b mike/master mike/master but it would not be caught by your rule. One area where your rule _is_ nicer than mine is that mine only looks at what exists _now_ and doesn't future-proof you at all. So I could say git checkout -b origin/newtopic which might not be ambiguous. But if the remote adds a "newtopic" branch, then the next time I fetch it will _become_ ambiguous. Potentially you could blacklist "X/*" for every remote.X.* that exists in your config. Even that, of course, isn't future-proof against you creating a new remote. :) I think the future-proofing is probably not worth the effort. Catching things that are ambiguous _now_ will cover the "oops, I typed the wrong thing" case, which I think is really the issue. -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
