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

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 1, 2025, 16:38 UTC
Message-ID: <xmqqcybnxvr2.fsf@gitster.g>
In-Reply-To: <20250531054618.GA30443@tb-raspi4>

Torsten Bögershausen <tboegi@web.de> writes:

Show 6 quoted lines

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

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

Show 14 quoted lines

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