Re: [PATCH 2/7] submodule foreach: correct path computation in recursive submodules

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 29, 2016, 19:00 UTC
Message-ID: <xmqqk2klxg6b.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <xmqq60w525yd.fsf@gitster.mtv.corp.google.com>

Junio C Hamano <gitster@pobox.com> writes:

Show 17 quoted lines

> Stefan Beller <sbeller@google.com> writes:
>
>> The test which is fixed by this patch would report
>>     Entering 'nested1/nested2/../nested3'
>> instead of the expected
>>     Entering '../nested1/nested2/nested3'
>>
>> because the prefix is put unconditionally in front and after that a
>> computed display path with is affected by `wt_prefix`. This is wrong as
>> any relative path computation would need to be at the front. By emptying
>> the `wt_prefix` in recursive submodules and adding the information of any
>> relative path into the `prefix` this is fixed.
>>
>> Signed-off-by: Stefan Beller <sbeller@google.com>
>> ---
>
> Nicely explained and executed.

Interestingly, this breakage, as 1/7 shows, only affects the "Entering $there" message--I somehow expected from reading the description above that the command given to "foreach" is run in a wrong submodule directory, but there is no such bug that is fixed by this change, as far as "foreach" is concerned.

Which might be an indication that it wasn't so "Nicely explained" after all X-<. Are there codepaths that use the same incorrect information (which was fixed by this patch) for things other than the message and chdir to an incorrect place? Then this change is fixing more than "just a bug in foreach message".

The explanation does not make it clear what the extent of the fix is, in other words.

Nevertheless, it is a good fix for "foreach message". Thanks. It just needs to clarify if that is the only change, or if it fixes other things.