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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux