Ramkumar Ramachandra <artag...@gmail.com> writes:

> Junio C Hamano wrote:
>> 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.

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