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

[Mark Mentovai <mark@chromium.org>]

Eric Sunshine wrote:
> However, have you tested this on Windows?

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

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

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