On Tue, Jan 31, 2012 at 04:22:58PM -0600, Jonathan Nieder wrote: > Forgetting the algorithms: > > (A) means "find what repository we are in the worktree for, or, > barring that, what bare repository we are in". > > (B) means "find which repository the user pointed to. To be extra > nice, we allow a '.git' extension to be left out, so the URL used > doesn't have to include the redundant information that this is a > git repository, and we even allow pointing to the toplevel of a > worktree instead of a repository, too." I can see that as a plausible interpretation. But I think your "means" is kind of vague. In other words, we are assigning a meaning that is not actually documented anywhere, and which we are hoping matches user expectations. So the correct behavior kind of depends on your mental model. IOW, I find your mental model plausible, but it is not the one that I had. But like I said, I'm OK either way. I'll prepare this fix with the least behavior change possible. Then doing your change on top should be a trivial rearrangement of the lookup arrays (the "hard" part for your proposed change is adding in the is_git_directory() calls[1], but I'll do that as part of mine). > I admit part of the reason I care is that just putting "" first would > probably taken care of the more important part of > <http://bugs.debian.org/399041>. Would that fix it? If I understand it, the repo in question is bare with a ".git" directory inside it. Your proposed change would make "git ls-remote foo" work, but wouldn't "cd foo && git log" still be broken? At the very least, it would show a completely different repo than ls-remote. -Peff [1] Without the is_git_directory() check, the ordering you propose breaks things very badly. Because if I point to a non-bare directory "foo", we say "OK, foo exists" and never look at "foo/.git". So instead, we have to say "OK, foo exists, but hey, it looks nothing like a .git directory" and keep trying. -- 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