Re: [PATCH] t7900: use pwd -P in macOS maintenance test
From: Eric Sunshine <hidden>
Date: 2025-05-23 20:08:14
On Fri, May 23, 2025 at 3:37 PM Mark Mentovai [off-list ref] wrote:
quoted hunk ↗ jump to hunk
$pfx is the basis for the expectation that launchd plist paths formed by `git maintenance start` will be compared against. These paths are formed in `git maintenance` by builtin/gc.c launchctl_service_filename(), which calls path.c interpolate_path() with real_home = 1, causing abspath.c strbuf_realpath() to resolve a canonical absolute path. Since $pfx is not determined according to the same realpath semantics, when t7900 is run from a working directory that contains a symbolic link in its path, the realpath operation will produce a different path than $pfx contains, although both paths logically reference the same directory. The test fails in this case. Base $pfx on the physical working directory (pwd -P), with all symbolic links fully resolved, so that the path that the test expects matches what `git maintenance` generates, even when running from a working directory whose path contains a symbolic link. Signed-off-by: Mark Mentovai <redacted> ---diff --git a/t/t7900-maintenance.sh b/t/t7900-maintenance.sh@@ -882,7 +882,7 @@ test_expect_success 'stop preserves surrounding schedule' ' test_expect_success 'start and stop macOS maintenance' ' # ensure $HOME can be compared against hook arguments on all platforms - pfx=$(cd "$HOME" && pwd) && + pfx=$(cd "$HOME" && pwd -P) &&
Okay, this seems like the minimum fix[*], and -P is POSIX.
However, have you tested this on Windows? I ask because, despite the
test's name, this and most of the tests in this script, are actually
run on all platforms, and because `pwd` is overridden by a shell
function for MinGW on Windows:
# t/test-lib.sh
...
# git sees Windows-style pwd
pwd () {
builtin pwd -W
}
My quick testing suggests that this patch's change might be problematic:
# on Windows
$ pwd
/home/me
$ pwd -W
C:/msys64/home/me
$ pwd -P
/home/me
$ pwd -W -P
/home/me
FOOTNOTES
[*]: In the long run, a better fix would probably be for the tests to
sanitize the output of the Git command, replacing (via `sed`) the
actual emitted path with some placeholder, such as "%HOME%" or
something, and then have the tests look for (`grep` or whatnot)
needles using that literal placeholder rather than trying to perfectly
match the path emitted by Git. This approach makes sense since these
tests are about overall functionality of git-maintenance, not about
the specific path in which the person happens to be running the tests.