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

From: Mark Mentovai <mark@chromium.org>
Date: Jun 2, 2025, 16:08 UTC
Message-ID: <f0d4c85a-b833-c52d-b54f-77ab81f22451@chromium.org>
In-Reply-To: <xmqqcybnxvr2.fsf@gitster.g>

Junio C Hamano wrote:

Show 22 quoted lines

> Torsten Bögershausen <tboegi@web.de> writes:
>
>> The word canonical has been removed.
>> After reading the help for
>> 'pwd -P' and 'cd -P'
>> "absolute" is replaced by "physical".
>> A matter of taste.
>> If absolute is more used here in Git, I am fine with any.
>
> It is OK as long as we are locally consistent.  I do think inside
> our codebase it seems we use "absolute" more, but the change in
> question is about use of "-P" option, which certainly was taken from
> "physical", in our test scripts, so I am OK with your description
> below to use that word.
>
> If somebody really cared (and I don't), we may want to pick a single
> word among physical, absolute, and real, but the only thing is that
> we are using them interchangeably, so as long as we make it clear
> (e.g. perhaps strbuf_realpath() and the underlying helper functions
> that are used by it may have a comment or two that says that we use
> these three words interchangeably to our developers), it would be
> good enough.

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.

There is no single term that's widely understood to have the meaning that this change is concerned with. "Physical" is a contender, but this term is not broadly understood without providing additional context. In fact, while "physical" is the namesake for the pwd's `-P` option, the POSIX definition of pwd(1) doesn't even use this term, instead explaining the concept fully in prose[3]. I don't believe it's appropriate to discuss "physical" paths without an introduction clarifying its intended meaning.

`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 canonicalization that may apply to a path, some filesystem-dependent. This change is concerned with canonicalization via symbolic link resolution, but in other contexts, path canonicalization may refer to other concepts, such as case matching on case-preserving filesystems, or encoding canonicalization (such as Unicode normalization) on filesystems that have defined encoding rules.

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.

I don't know that this amount of scrutiny of a commit message that's precise and correct is entirely justified, but if there's a strong preference to converge on a single term, provided that it's not technically inaccurate, I'll accede to the request. I don't expect that it will shrink the amount of explanatory text, though, because as I've illustrated, there isn't really a term in existence that conveys this principle generally in a way that's suitable for broad understanding.

[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 [3] https://pubs.opengroup.org/onlinepubs/9799919799/utilities/pwd.html [4] https://pubs.opengroup.org/onlinepubs/9699919799/functions/realpath.html [5] https://sourceware.org/glibc/manual/2.41/html_node/Symbolic-Links.html#index-realpath [6] https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/man/man3/realpath.3

Show 39 quoted lines

>> ==================================================
>> t: run 7900 tests from the physical working directory
>>
>> Some tests make git perform actions that produce observable pathnames,
>> and have expectations on those paths. Tests run with $HOME set to a
>> $TRASH_DIRECTORY, and with their working directory the same
>> $TRASH_DIRECTORY, although these paths are physical identical, they do
>> not observe the same pathname normalization rules and thus might not
>> be represented by strings that compare equal.
>> In particular, no pathname
>> normalization is applied to $TRASH_DIRECTORY or $HOME, while tests
>> change their working directory with `cd -P` which resolves symbolic links
>> returning the physical path.
>
> "physical identical"?  I think the problem is $HOME and $TRASH are
> the same but not physically normalized, which means "cd $HOME &&
> pwd", "cd $HOME && pwd -P" and "cd -P $HOME && pwd" can give
> different results from these two variables.  How about replacing the
> latter half of the above with something much simpler, like this?
>
>    ... although HOME and TRASH_DIRECTORY have identical values, the
>    physical path to it (i.e. what "cd $HOME && pwd -P" reports) may
>    be different.
>
>> t7900's macOS maintenance tests (which are not limited to running on
>> macOS) have an expectation on a path that `git maintenance` forms by
>> using abspath.c strbuf_realpath() to resolve the physical path
>> based on $HOME. When t7900 runs from a working directory that contains
>> symbolic links in its pathname, $HOME will also contain symbolic links,
>> which `git maintenance` resolves but the test's expectation does not,
>> causing a test failure.
>>
>> Align $TRASH_DIRECTORY and $HOME with the physical path as used for
>> the working directory by resetting them to match the working directory
>> after it's established by `cd -P`. With all paths in agreement and
>> symbolic links resolved, pathname expectations can be set and met based
>> on string comparison without regard to external environmental factors
>> such as the presence of symbolic links in a path.
>