Re: git checkout -b origin/mybranch origin/mybranch

From: Jeff King <peff@peff.net>
Date: Mar 12, 2009, 16:35 UTC
Message-ID: <20090312163533.GA28205@coredump.intra.peff.net>
In-Reply-To: <43d8ce650903120916yb91113fy5485813c512c8108@mail.gmail.com>

On Thu, Mar 12, 2009 at 04:16:09PM +0000, John Tapsell wrote:

Show 5 quoted lines

> 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