From: Junio C Hamano <gitster@pobox.com>
Date: Mon, 13 May 2013 04:54:22 GMT
Subject: Re: [PATCHv2 04/10] remote: Reject remote names containing '/'
Message-ID: <7vtxm7scn5.fsf@alter.siamese.dyndns.org>
In-Reply-To: <1368289280-30337-5-git-send-email-johan@herland.net>

Johan Herland <johan@herland.net> writes:

> Although we definitely support and encourage use of multi-level branch
> names, we have never conciously tried to give support for multi-level
> remote names. Currently, they are allowed, but there is no evidence that
> they are commonly used.
>
> Now, they do provide a source of problems when trying to expand the
> "$nick/$name" shorthand notation (where $nick matches a remote name)
> into a full refname. Consider the shorthand "foo/bar/baz": Does this
> parse as $nick = foo, $name = bar/baz, or $nick = foo/bar, $name = baz?
>
> Since we need to be unambiguous about these things, we hereby declare
> that a remote name shall never contain a '/' character, and that the
> only correct way to parse "foo/bar/baz" is $nick = foo, $name = bar/baz.

I know I am guilty of hinting to go in this direction in the earlier
discussion, but I have to wonder how much more refactoring is needed
to see if there is only one unique possibility among many.

For a string with N slashes, you have only N possible ways to split
it into $nick and $name, and if you see a ref "bar/baz" copied from
remote "foo" but no ref "baz" copied from remote "foo/bar" (or you
may not even have a remote "foo/bar" in the first place), the user
is already very unambiguous. The declaration is merely being lazy.

I am not saying we must implement such a back-track to disambiguate
the user input better.  I am wondering how much more effort on top
of this series is needed if we want to get there (provided that the
disambiguation is a good thing to do in the first place).