Re: git checkout -b origin/mybranch origin/mybranch
- From
John Tapsell <johnflux@gmail.com>
- Date
- Mar 12, 2009, 16:16 UTC
- Message-ID
- <43d8ce650903120916yb91113fy5485813c512c8108@mail.gmail.com>
- In-Reply-To
- <20090312153738.GA24690@coredump.intra.peff.net>
2009/3/12 Jeff King <peff@peff.net>:
Show 28 quoted lines
> 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 >