"Alex Riesen" [off-list ref] 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. From the beginning we
deliberately omitted .git suffix to keep the resulting log
message short and sweet. Keeping .git suffix goes against it.
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.
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.
Junio C Hamano, Wed, Jun 06, 2007 22:07:24 +0200:
"Alex Riesen" [off-list ref] writes:
quoted
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.
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