Jakub Narebski <jnareb@xxxxxxxxx> writes: > Jeff King <peff@xxxxxxxx> writes: > >> 1. Is there some other syntax that _doesn't_ have this breakage >> but that similarly helps the "vast majority of Git users". > > Well, proposed possible syntax was: > 1. <vcs>:<repository location> > ... > 2. <vcs>::<repository location> > ... > 3. <vcs>+<repository location> > > e.g. > > svn+http://svn.example.com/project > > but > > http+svn://svn.example.com/project > svn+path/to/repo I do not think these are valid examples to demonstrate that 3 is bad. We do not have (and we will not create) "http+svn://" native transport, so the former can only mean "Feed 'svn://svn.example.com/project' to the vcs helper whose name is 'http'". Similarly I do not see any way to read the latter other than "Feed 'path/to/repo' to 'svn' vcs helper". We do have a pair of synonyms "git+ssh://foo" and "ssh+git://bar" that could make the use of '+' ambiguous. They could be feeding 'ssh://foo' and 'git://bar' to 'git' and 'ssh' vcs helpers respectively, but (1) they are not even advertised in Documentation/ anywhere as far as I can see; and (2) these are the only two existing ones that are misdesigned, and we can easily special case them to keep backward compatibility. Double-colon (your 2) is also workable. It probably is slightly better than plus because it does not have to grandfather "git+ssh" and "ssh+git" and that would be beneficial for requiring less complexity in both code (i.e. special case logic) and more importantly in mental burden to the end users (i.e. '::' would stand out more than '+' and clearly different from traditional git URLs in all cases). As Jeff said (your 1.), a single colon ':' has a rather bad ambiguity between <vcs> and hostname part in the existing scp-style repository naming. -- 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