Junio C Hamano, Wed, Jun 06, 2007 22:07:24 +0200:
> "Alex Riesen" <raa.lkml@xxxxxxxxx> 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.
> 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
