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".
Does that actually cover all of the problematic cases?
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
