Junio C Hamano <gitster@xxxxxxxxx> writes: > Ramkumar Ramachandra <artagnon@xxxxxxxxx> writes: > >> The reader is now wondering what this could possibly be, and why you >> didn't send this patch earlier. > > Because it wasn't written back then? > >> Perhaps clarify with: s/there are >> cases/there may be cases/ and append "One such case that we currently >> don't handle yet is a path inside another git repository in our >> worktree, as demonstrated by test tXXXX.X." > > I think "we currently don't handle" is a misstatement. It is not a > bug that we don't. We can think of it this way. In your working tree, there is an upper bound for the paths you can include in your commit. When you are at the top-level of your working tree, you do not say "git add ../f" or "git add ../d/f". The root-level of your working tree is an upper bound and you do not cross that boundary. It turns out that there are lower bounds for the paths as well. When we say "Git tracks symbolic links", anything that appears beyond a symbolic link is beyond that boundary. If we track a symbolic link "l", we can of course add "l". When "l" leads to a directory somewhere else, the filesystem gives you an illusion that there are things under "l" (e.g. "l" points at "/etc" and there is "l/passwd" there), but that is beyond the boundary. You do not add "l/passwd". Otherwise "git add l" would become meaningless. Does it add the symbolic link itself, or all the files in there, pretending "l" is actually a directory? We have chosen to say it is the former, and apply that rule consistently. It is the same for "Git tracks submodules", which defines that the top-level of the submodule working tree as such a lower boundary. -- 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