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?
One is the implementation of (A):
cd foo
git rev-parse --git-dir
The other implements (B):
git ls-remote foo
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.
2) As a naive user, I would expect (A) to give a different result
from (B).
Hope that helps,
Jonathan
[*] ok, ok, they can be confused instead of insane:
http://bugs.debian.org/399041
--
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