On Tue, Oct 16, 2007 at 11:49:58 +0100, Johannes Schindelin wrote:
quoted text
> In related news, I recently thought about the url#branch issue.
>=20
> There were three arguments against it AFAIR: "#" is a comment marker, and=
=20
quoted text
> this syntax is not extensible to more than one branch names.  And that th=
e=20
quoted text
> branch name is not really a part of the URL.
>=20
> Turns out that I am not so sure about the last two issues.
>=20
> It is easily extensible to more than one branch by remote#branch1#branch2=
,=20
quoted text
> and in a very real sense, this is a resource locator.
>=20
> And we could replace the "#" by every character that is illegal in ref=20
> names as well as URLs.  I propose SPC.  ('#' is allowed in refnames.)

It's a question, whether the branch name is part of the URI, or a fragment.

Current usage suggests it is a fragment, but according to the URL
specification that is supposed to mean that the resource is always accessed
the same (fragment is NOT part of the URL) and the fragment only affects
local handling. Which I don't think is really true.

If it is a fragment, than "#" is the only correct separator and should stay
that way.

If it is not a true fragment, than we might want to phase it out in favor of
something else. But I would strongly prefer staying within characters allow=
ed
in URI (as per rfc2396). We could consider whether the branch is not
a component parameter -- which would imply ";" as separator, but I would vo=
te
against that on the basis that it's shell special. Non-special characters
allowed by URL in this context would be ":", "@", "=3D", "+", and ",", of w=
hich
":" or "@" seem best to me.

As for multiple branches, separating them with "," feels logical to me, no
matter what separates them from the repository path. On the other hand given
that neither ":" nor "@" is allowed in refnames, reusing the same separator
would make sense especially if git switched to either of those.

--=20
						 Jan 'Bulb' Hudec <bulb@ucw.cz>