On 6/6/07, Junio C Hamano <gitster@xxxxxxxxx> wrote:
"Alex Riesen" <raa.lkml@xxxxxxxxx> writes: > Otherwise ".git" is removed from every remote name which has it: > > $ git fetch -v > * refs/heads/origin: same as branch 'master' of /home/user/linux > commit: 5ecd310 > $ ls /home/user/linux > ls: /home/user/linux: No such file or directory > $ ls /home/user/linux.git > HEAD objects packed-refs ... I suspect the above misses the point.
Depends on the point. I mean to say: the path in the output of the command does not exist anywhere.
The test "ls /home/user/linux" is not relevant. Ability to say "git fetch /home/user/linux" is.
This is still ambiguous: $ git fetch -v /home/user/a * fetched /home/user/a commit: b85c140 $ git fetch -v /home/user/a.git * fetched /home/user/a commit: b85c140 Which one was fetched when? /home/user/a or /home/user/a.git? No imagine you don't see the command (as if git fetch is called in some frontend). Would you be able to distinguish the sources? Besides, I just noticed git-clone is broken WRT the .git as well: I can clone a "a.git" into "b" (and it ignores -l and -s!), but I can't fetch the "a" (aka "origin") being in "b". And of course, "origin" in "b" is setup as "/path/a", not "/path/a.git". - 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
