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

Ramkumar Ramachandra [off-list ref] writes:

Junio C Hamano wrote:

quoted

But there are other cases to attempt to add a path that do not
belong to our project, which do not have to involve a symbolic link
in the leading path.

The reader is now wondering what this could possibly be, and why you
didn't send this patch earlier.  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_ I misread what you meant to say in the above.

We can go either way between "are cases" or "may be cases".  I meant
it as an immediate predecessor ([PATCH 1/n]) to the patch you were
working on ([PATCH 2/n] and later), so in that context, it does not
matter.  [PATCH 2/n] will start as "Now the naming is saner, let's
start noticing when the user gives a path is beyond our project
boundary because it is under control of another repository by adding
necessary logic to that function."

And I also misread "we currently don't handle" above as "but we
really should allow adding d/f when d is at the top of the working
tree of another project", but that was not what you meant to say.
Instead, "We do not notice such a bad case in today's code yet" was
what you meant.  But if we are to use "there are cases" in [1/n] and
start [2/n] with "Now we have renamed, let's do this", then we do
not have to bother saying anything in [1/n] about the upcoming
change in [2/n], especially the patches come back-to-back in a
single series.

Junio C Hamano wrote:

And I also misread "we currently don't handle" above as "but we
really should allow adding d/f when d is at the top of the working
tree of another project", but that was not what you meant to say.
Instead, "We do not notice such a bad case in today's code yet" was
what you meant.  But if we are to use "there are cases" in [1/n] and
start [2/n] with "Now we have renamed, let's do this", then we do
not have to bother saying anything in [1/n] about the upcoming
change in [2/n], especially the patches come back-to-back in a
single series.

Exactly.  Yeah, I don't think you patch makes sense as a standalone
anyway: I'll use appropriate wording when I roll the series, so it
follows nicely.