NO.
The thing is, we'd be much better off being consistent with OURSELVES than
with something else!
Nobody cares about git being consistent with a web browser. There is
nothing in common.
But I *do* care about git being consistent with itself. If I do
git clone /some/directory
and then decide that I want to generate a new pack and change it into
git clone file:///some/directory
I don't want to have to re-write the thing to quote differently!
The same very much goes for a path like
git://git.kernel.org/<path>
vs
master.kernel.org:<path>
because I will use the two interchangably. They *are* the same address,
except:
- the "git://" protocol is a bit faster, since the ssh connection
overhead is actually big enough to be quite noticeable.
- but I often use the master.kernel.org:<path> thing because there's a
mirroring delay that means that accessing it directly is sometimes
preferable.
See? THAT is where we need to be consistent: with our own paths!
[ And yes, I literally really do switch things around exactly like that
between ssh accesses and the git:// protocol. That was not a made-up
example, but real usage! ]
In contrast, nobody has _ever_ given a real technical reason to care about
the Web URL RFC at all.
Really. It's that simple: if you cannot argue for something without
pointing to an irrelevant standard, you really shouldn't argue for it in
the first place.
People who make decisions based on "it's a standard" make *sub*standard
decisions. The fact is, most standards are not worth even using as toilet
paper, because they were designed by some committee that wanted to reach
"consensus". That's just crap.
Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
