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

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 21, 2008, 23:35 UTC
Message-ID: <7v8wshwmgt.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <7vd4htwp6v.fsf@gitster.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

Show 20 quoted lines

> 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*].
> ...
> [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.

Actually, after looking at what the involved codepaths do, I am inclined to change my mind. Somehow I thought the transport.c infrastructure DWIMs and uses the result of DWIMmery throughout the program (iow, at the point in the codepath the patch touches, we cannot tell what the user originally asked for), which is not the case at all. That changes everything.

The current behaviour is Ok if you match your behaviour to the original expectations, but:

 * if you clone from "git://$somewhere/project" originally, your
   remote.origin.url will not end with ".git";

 * or equivalently, if your remote.origin.url does not end with ".git".

and when you fetch in such a repository with or without the patch, the results are the same. URL without trailing ".git".

So the change in the behaviour is only when you originally explicitly asked to clone "git://$somewhere/project.git". With the change, that wish is preserved. Without the change, ".git" is unconditionally dropped.

The situation is the same if you explicitly ask to fetch from a URL that ends with ".git" (or "/.git"). With the change, the explicit ".git" is preserved; without it, it is dropped.

So I now think the patch (if it were massaged into an applicable shape with proper log message and sign-off) is an improvement.

Alex, thanks for sanity checking ;-)