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

> Stefan Beller <sbel...@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 <sbel...@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.

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