Re: [PATCH] git-fetch should not strip off ".git" extension

"Alex Riesen" [off-list ref] writes:

2008/10/21 Junio C Hamano [off-list ref]:

quoted

"Leo Razoumov" [off-list ref] writes:

quoted

Even though the old behavior is "long established", it introduces
unnecessary ambiguity. If I have two repos
...

Of course.  Now you know why people don't name such a pair of repositories
like that ;-).

FWIW, I support Leo on that. The "established" behavior is stupid.

I am not inclined to respond to such an emotional argument.  On the other
hand, it is fair to say that the existing behaviour is established,
because it is backed by a long history, which you can objectively verify.

If you think about it deeper, you will realize that it is not even clear
if it is "stupid".

More importantly, the behaviour is consistent with the way how "git fetch"
and "git clone" DWIMs the repository name by suffixing .git when the input
lacks it.  And this DWIMmery comes from the expectations that:

 (1) people name their repository project.git; and

 (2) people like using and seeing short names (iow, "clone
     git://$somewhere/project" is preferred over "clone
     git://$somewhere/project.git");

If a repository whose real location is git://$somewhere/project.git is
cloned/fetched as git://$somewhere/project by people, recording the merge
source using the shorter name used by people to fetch from it is more
consistent.  The patch breaks this consistency [*1*].

What is clear is that you would confuse yourself if you have two
repositories A and A.git next to each other, and that is primarily because
it breaks the above expectation.

git core-level rarely imposes such policies, but what Porcelains do is a
different matter.

Hence the suggestion: don't do it.

[Footnote]

*1* It would be a different matter if the patch at the same time removed
the fetch/clone DWIMmery.  At least such a patch would be internally self
consistent.