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

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 9, 2013, 20:31 UTC
Message-ID: <7vzjx7phti.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CALkWK0nF0aTLDZyPXfa=4kp=BnDPm3+_ZfMvP_6ZcimeJtzxvw@mail.gmail.com>

Ramkumar Ramachandra <artagnon@gmail.com> writes:

Show 10 quoted lines

> 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.