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

From: Jeff King <peff@peff.net>
Date: Mar 12, 2009, 15:37 UTC
Message-ID: <20090312153738.GA24690@coredump.intra.peff.net>
In-Reply-To: <B9479687-D936-4EE1-A5A4-663968B76EBF@ai.rug.nl>

On Thu, Mar 12, 2009 at 03:21:48PM +0000, Pieter de Bie wrote:

Show 8 quoted lines

> 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".

Does that actually cover all of the problematic cases?

-Peff