Junio C Hamano <gits...@pobox.com> writes:

> Ramkumar Ramachandra <artag...@gmail.com> 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to