David Kastrup <d...@gnu.org> writes:

> Junio C Hamano <gits...@pobox.com> writes:
> ...
>>  A. Because it will confuse you.
>>  B. I know what I am doing.
>>  A. ???
> A. But maybe Git will no longer know what you are doing.  Its standard
> way of resolving references will mean that once a branch
> refs/heads/wibble exists, referring to a branch wibble will become extra
> hard.  For example, stuff like
> push origin HEAD:refs/heads/wibble
> will maybe create or update a new branch wibble, or maybe it will just
> push to the existing branch refs/heads/wibble.

I suspect that is a bad example (do refs on _our_ side influence how
RHS of the colon that names refs on the other side is interpreted),
but I think I know what you are trying to say.  But Git never knows
what you are doing---it just does what you tell it to, so it comes
back to "It will confuse you to the point that you would not be able
to guess what Git will do matches your expectation".  Whenever I
tell them that, a counterpoint B. makes is still "I know what I am
doing.", which is stubborn, rather obvious, and unfortunate.

How much of the namespace are we willing to carve out if we were to
go this route anyway?  Things we use, i.e. refs/heads and refs/tags,
would be no-brainers, but do we also forbid refs/review, which we
ourselves do not use but some people may have in their repositories?
Anything that begins with refs/?  Anything that begins with refs/
and has more than two slashes in it?

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to