Jeff King wrote: > Right. But would you expect: > > git ls-remote foo > > to behave the same as: > > cd foo > git ls-remote . > > and would you furthermore expect that to behave the same as: > > cd foo > git rev-parse --git-dir > > ? Nah. I never run "git ls-remote .". ;-) [...] >> 2) As a naive user, I would expect (A) to give a different result >> from (B). > > Why? Normally git commands expect me to be in (possibly a deeply nested subdirectory) of the worktree. The typical case is a non-bare repository. I have been taught that it walks to the toplevel and finds a ".git" directory. By contrast, the path passed to git transport commands like "git fetch otherhost:/foo/bar/baz.git" is a path to the git repository metadata. I am not allowed to pass a path to a subdirectory, for example. As a user, when would the distinction ever come up? One is a fuzzy "which repository am I working in", and the other is a precise "point me to the metadata directory, but I allow you to abbreviate a little by leaving out the trailing .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