Re: [PATCH 2/2] add: refuse to add paths beyond repository boundaries

Junio C Hamano [off-list ref] writes:

Ramkumar Ramachandra [off-list ref] writes:

quoted

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?

quoted

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.