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

[John Tapsell <johnflux@gmail.com>]

2009/3/12 Jeff King <peff@peff.net>:
> 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.

Yep, makes sense.

I suppose you could do both.  Blacklist and check if it already
exists, but I think just checking if it exists is "good enough".

John