Ramkumar Ramachandra <artagnon@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html