"Alex Riesen" [off-list ref] 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.
The test "ls /home/user/linux" is not relevant. Ability to say
"git fetch /home/user/linux" is.
On 6/6/07, Junio C Hamano [off-list ref] wrote:
"Alex Riesen" [off-list ref] writes:
quoted
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".