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

> "Alex Riesen" <raa.lkml@gmail.com> writes:
>
>  > 2008/10/21 Junio C Hamano <gitster@pobox.com>:
>  >> "Leo Razoumov" <slonik.az@gmail.com> writes:
>  >>
>  >>> 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.
>