On Tue, Jan 31, 2012 at 03:40:47PM -0600, Jonathan Nieder wrote: > Jeff King wrote: > > > No, it does not match. While the sequence I outlined above makes the > > most sense to me, it does not match what setup_git_directory does, which > > prefers "foo/.git" to using "foo" as a bare repo. I think being > > consistent between all of the lookup points makes sense. The patch took > > the least-invasive approach and aligned clone and enter_repo with > > setup_git_directory. > > > > However, we could also tweak setup_git_directory to prefer bare repos > > over ".git" to keep things consistent. While it makes me feel good from > > a theoretical standpoint (because the rules above seem simple and > > intuitive to me), I'm not sure it's a good idea in practice. > > Wait, don't these two functions serve two completely different purposes? Yes, but I would expect the lookup to be the same. > One is the implementation of (A): > > cd foo > git rev-parse --git-dir > > The other implements (B): > > git ls-remote foo 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 ? Maybe I am crazy, but I see all of them as ways of specifying "I am interested in repository foo", and any lookup magic should be the same in all cases. > If "foo" is actually a bare repository that moonlights as a worktree for > a non-bare repository, then: > > 1) Whoever set up these directories is completely insane[*]. Maybe we > should emit a warning. Yes, I think we are dealing with an insane corner case. > 2) As a naive user, I would expect (A) to give a different result > from (B). Why? -Peff -- 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