Re: [PATCH v2] t: run tests from a normalized working directory

[Mark Mentovai <mark@chromium.org>]

Torsten Bögershausen wrote:
> On Mon, Jun 02, 2025 at 02:32:35PM -0700, Junio C Hamano wrote:
>> Mark Mentovai <mark@chromium.org> writes:
>>
>>> `realpath` is a library interface that transforms paths to those
>>> having the semantics at issue, but it's somewhat obscure, and easily
>>> confused with "real path" whose meaning would be entirely
>>> ambiguous. realpath(3) documentation from POSIX[4] explains the
>>> semantics fully; glibc[5], and Linux man-pages[6] provide full
>>> explanation while also using the term "canonicalize".
>>>
>>> "Canonicalize" alone is too generic, because there are several axes of
>>
>> Yes.  You need to specify what you are canonicalizing to, and once
>> you are going to do so, there is no need for that heavy verb, i.e.
>> you do not need to say "canonicalize it to realpath"---you say "turn
>> it into realpath" and you convey what you want to say just fine.
>>
>>> All of this illustrates the difficulty in choosing a single term to
>>> unambiguously convey the meaning. I chose to write a commit message
>>> that favored technical precision, even if it meant tending toward what
>>> Junio called "the more verbose and repetitive side". I believed that
>>> to be necessary to fully explain the background, the problem, and the
>>> solution.
>>
>> Yup, that is why I said I thought your original was clear enough.
>>
>> I am tempted to say that we take what we have from you and merge it
>> down.
>>
>
> Thanks for the long explanations.
> I still stumble across the headline:
> t: run tests from a normalized working directory
>
> Re-reading the help for realpath() and pwd, would this makes sense:
> t: run tests from an absolute pathname

No. As I wrote earlier:

> An "absolute" path is well-defined and commonly understood to have a
> singular meaning. These paths are relative to the root directory, and are 
> identified by a leading separator (/). POSIX specifies this at XBD.3.2[1] 
> and XBD.4.16[2].
>
> This change is not concerned with absolute paths. All of the paths in
> question are absolute, both before and after this change.
[...]
> [1] https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap03.html#tag_03_02
> [2] https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap04.html#tag_04_16

Making a path absolute is a different transformation than what is at issue 
here. You may have been misled by the fact that pwd -P and realpath both 
make paths absolute in addition to performing symbolic link resolution. 
The latter is what's operative here.

As I've explained, the paths in question are already absolute in git's 
test suite today, even without the proposed change. It's not correct to 
summarize the change as making paths absolute, when that's neither 
changing nor the crux of the problem.