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 03:21:48PM +0000, Pieter de Bie wrote:
>
>> You can also get this in other interactions, for example:
>>
>>       $ git checkout -b origin/test HEAD
>>       $ git checkout -b origin/test master
>>
>> yes, these might be user errors, but I still think it's not OK to create a
>> new ref 'refs/heads/origin/test' if there's also a 'refs/
>> remotes/origin/test' (as I've said a few months ago).
>
> One thing that has been missing from this discussion (and I think you
> are getting to it here) is a concrete rule for "X is harmful, and Y is
> not". That is, how do we know when to warn, and then what do we do?
>
> John's original example was "git checkout -b origin/test origin/test".
> So it's a problem that they're textually the same, but obviously there
> are more problematic cases.
>
> The behavior I think you are implying would be something like:
>
>  When making origin/test, try to resolve_ref("origin/test"); if it
>  fails, we are OK. If it succeeds, then we know we will be creating an
>  ambiguity. Complain and refuse the creation unless "-f" is given.
>
> This would actually be a superset of the "branch already exists" case,
> so it should be pretty simple to code, and it makes for a simple rule:
> it is now "ref already exists".

+1

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 ?


> Does that actually cover all of the problematic cases?
>
> -Peff
>