Re: [PATCH] t7900: use pwd -P in macOS maintenance test

From: Mark Mentovai <mark@chromium.org>
Date: May 23, 2025, 20:43 UTC
Message-ID: <88e8231f-7c08-652d-f734-22c4632aa728@chromium.org>
In-Reply-To: <CAPig+cRpS=t-wNLxdV_WoKF0Wzy-S1oLUEyS18S9r-4OBQ87VQ@mail.gmail.com>

Eric Sunshine wrote:

> However, have you tested this on Windows?

Yes, via the CI: https://github.com/markmentovai/git/actions/runs/15217563313.

Show 11 quoted lines

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

That MinGW fallback pwd ignores arguments, so any pwd in a test regardless of whether it's specified as pwd or pwd -P will result in an underlying pwd -W. The t7900 test's behavior should not change as a result of this patch. If it's succeeding in some MinGW environment before this patch, it'll continue to succeed after.

Show 22 quoted lines

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

The specific front of the path is not important, but the tail should be as expected, and I suspect that it remains much less fragile and complex to perform this equality comparison than it would be to try to reason about the path's inner components.

The existing print-args in this test could be modified as you propose, but the changes would also need to spill into the "start and stop when several schedulers are available" test later in the same file. That seems more invasive and produces less clear test code than just calculating a path expectation in line with what git maintenance uses in the first place.