"Alex Riesen" <raa.lkml@xxxxxxxxx> writes: > On 6/6/07, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> 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: Yup, there is an ambiguity. Always has been. > Which one was fetched when? /home/user/a or /home/user/a.git? I am half tempted to say that this is very close to "doctor, it confuses me when I have both of them". Imagine the case where the source were a remote repository _and_ there was no way other than interacting with it via git protocol. You cannot really tell (well, you can tell half, by trying both and if a worked but a.git didn't you can tell that a.git does not exist) nor you do not really care. > 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". This probably is worth fixing, independent from what the message says before or after your patch. - 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
