Re: [PATCH] Fix the remote note the fetch-tool prints after storing a fetched reference

From: Alex Riesen <raa.lkml@gmail.com>
Date: Jun 6, 2007, 22:48 UTC
Message-ID: <20070606224841.GA3969@steel.home>
In-Reply-To: <7vfy543kzn.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano, Wed, Jun 06, 2007 22:07:24 +0200:

Show 18 quoted lines

> "Alex Riesen" <raa.lkml@gmail.com> writes:
> 
> > Otherwise ".git" is removed from every remote path which has it,
> > including "/some/path/somename.git".
> 
> I was very tempted to apply this patch, but after re-reading it
> once more, I decided to drop it.
> 
> I do not mind keeping the extra .git/ suffix in the -v output in
> your example, as the message is just "verbose information":
> 
>   $ git fetch -v
>     * refs/heads/origin: same as branch 'master' of /home/user/linux
>       commit: 5ecd310
> 
> But the same output is used by log messages for the merge
> commits; indeed, the primary purpose of this output is to
> prepare messages for merge commits.

BTW, this is hard to believe. Were does git-merge call fetch--tool? Nor have I found its use for logging purposes. Or, if you refer to the logs a user can create by redirecting output of git fetch someplace, than it is highly suspicious for tham to contain something short, sweet and not existing.

> From the beginning we deliberately omitted .git suffix to keep the
> resulting log message short and sweet.  Keeping .git suffix goes
> against it.

But this is how the repo is actually named! If you want to keep the _message_ short and sweet than cut the suffix in the message generation code.

> A repository "git://$site/repo.git" can be accessed with
> "git://$site/repo".  Repository owners _can_ confuse their users
> by having both repo and repo.git, but I honestly do not see a
> reason to encourage that.

People will never know whether they are encouraged or discouraged. They just wont notice it is _wrong_ until they copy-paste the path from git-fetch output and do something nasty to it.

Show 5 quoted lines

> Earlier you mentioned you know of a case where "$URL/repo.git"
> exists and "$URL/repo" does not, and the current clone fails to
> set up the target repository after cloning from "$URL/repo"
> correctly?  I admit I haven't reproduced nor debugged it, but if
> that is the case that needs to be fixed.

    mkdir a.git && cd a.git && git init && :>file && \
    git add . && git commit -m1 && mv .git/* . && rmdir .git && \
    cd .. && git clone -l -s a b && cd b && git fetch

The cloned repo "b" gets "a" verbatim, instead of something more useful (like "../../a.git" or "/full/path/a.git". It is not even "/full/path/a").

git clone works correctly (origin's url is an absolute path) if a.git is given:

    mkdir a.git && cd a.git && git init && :>file && \
    git add . && git commit -m1 && mv .git/* . && rmdir .git && \
    cd .. && git clone -l -s a.git b && cd b && git fetch

Fix, needed because of all this "detachable suffix" confusion:

diff --git a/git-clone.sh b/git-clone.sh
index fdd354f..d45618d 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -20,7 +20,7 @@ usage() {
 get_repo_base() {
 	(
 		cd "`/bin/pwd`" &&
-		cd "$1" &&
+		cd "$1" || cd "$1.git" &&
 		{
 			cd .git
 			pwd