{"thread":{"id":"63510","subject":"[PATCH] t7900: use pwd -P in macOS maintenance test","startedAt":"2025-05-23T19:37:25Z","lastAt":"2025-06-03T18:22:37Z","messageCount":19,"participants":["Mark Mentovai","Eric Sunshine","Junio C Hamano","Torsten Bögershausen"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"518799","messageId":"20250523193722.68344-1-mark@chromium.org","threadId":"63510","inReplyTo":null,"subject":"[PATCH] t7900: use pwd -P in macOS maintenance test","fromName":"Mark Mentovai","fromEmail":"mark@chromium.org","sentAt":"2025-05-23T19:37:22Z","receivedAt":"2025-05-23T19:37:25Z","isPatch":true,"sender":{"key":"mark@chromium.org","avatar":"https://avatars.githubusercontent.com/u/933273?v=4"},"body":"$pfx is the basis for the expectation that launchd plist paths formed by\n`git maintenance start` will be compared against. These paths are formed\nin `git maintenance` by builtin/gc.c launchctl_service_filename(), which\ncalls path.c interpolate_path() with real_home = 1, causing abspath.c\nstrbuf_realpath() to resolve a canonical absolute path. Since $pfx is\nnot determined according to the same realpath semantics, when t7900 is\nrun from a working directory that contains a symbolic link in its path,\nthe realpath operation will produce a different path than $pfx contains,\nalthough both paths logically reference the same directory. The test\nfails in this case.\n\nBase $pfx on the physical working directory (pwd -P), with all symbolic\nlinks fully resolved, so that the path that the test expects matches\nwhat `git maintenance` generates, even when running from a working\ndirectory whose path contains a symbolic link.\n\nSigned-off-by: Mark Mentovai <mark@chromium.org>\n---\n t/t7900-maintenance.sh | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/t/t7900-maintenance.sh b/t/t7900-maintenance.sh\nindex 8cf89e285f49..677e92f1490e 100755\n--- a/t/t7900-maintenance.sh\n+++ b/t/t7900-maintenance.sh\n@@ -882,7 +882,7 @@ test_expect_success 'stop preserves surrounding schedule' '\n \n test_expect_success 'start and stop macOS maintenance' '\n \t# ensure $HOME can be compared against hook arguments on all platforms\n-\tpfx=$(cd \"$HOME\" && pwd) &&\n+\tpfx=$(cd \"$HOME\" && pwd -P) &&\n \n \twrite_script print-args <<-\\EOF &&\n \techo $* | sed \"s:gui/[0-9][0-9]*:gui/[UID]:\" >>args\n-- \n2.49.0\n\n"},{"id":"518801","messageId":"CAPig+cRpS=t-wNLxdV_WoKF0Wzy-S1oLUEyS18S9r-4OBQ87VQ@mail.gmail.com","threadId":"63510","inReplyTo":"20250523193722.68344-1-mark@chromium.org","subject":"Re: [PATCH] t7900: use pwd -P in macOS maintenance test","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2025-05-23T20:08:02Z","receivedAt":"2025-05-23T20:08:14Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Fri, May 23, 2025 at 3:37 PM Mark Mentovai <mark@chromium.org> wrote:\n> $pfx is the basis for the expectation that launchd plist paths formed by\n> `git maintenance start` will be compared against. These paths are formed\n> in `git maintenance` by builtin/gc.c launchctl_service_filename(), which\n> calls path.c interpolate_path() with real_home = 1, causing abspath.c\n> strbuf_realpath() to resolve a canonical absolute path. Since $pfx is\n> not determined according to the same realpath semantics, when t7900 is\n> run from a working directory that contains a symbolic link in its path,\n> the realpath operation will produce a different path than $pfx contains,\n> although both paths logically reference the same directory. The test\n> fails in this case.\n>\n> Base $pfx on the physical working directory (pwd -P), with all symbolic\n> links fully resolved, so that the path that the test expects matches\n> what `git maintenance` generates, even when running from a working\n> directory whose path contains a symbolic link.\n>\n> Signed-off-by: Mark Mentovai <mark@chromium.org>\n> ---\n> diff --git a/t/t7900-maintenance.sh b/t/t7900-maintenance.sh\n> @@ -882,7 +882,7 @@ test_expect_success 'stop preserves surrounding schedule' '\n>  test_expect_success 'start and stop macOS maintenance' '\n>         # ensure $HOME can be compared against hook arguments on all platforms\n> -       pfx=$(cd \"$HOME\" && pwd) &&\n> +       pfx=$(cd \"$HOME\" && pwd -P) &&\n\nOkay, this seems like the minimum fix[*], and -P is POSIX.\n\nHowever, have you tested this on Windows? I ask because, despite the\ntest's name, this and most of the tests in this script, are actually\nrun on all platforms, and because `pwd` is overridden by a shell\nfunction for MinGW on Windows:\n\n    # t/test-lib.sh\n    ...\n    # git sees Windows-style pwd\n    pwd () {\n        builtin pwd -W\n    }\n\nMy quick testing suggests that this patch's change might be problematic:\n\n    # on Windows\n    $ pwd\n    /home/me\n    $ pwd -W\n    C:/msys64/home/me\n    $ pwd -P\n    /home/me\n    $ pwd -W -P\n    /home/me\n\nFOOTNOTES\n\n[*]: In the long run, a better fix would probably be for the tests to\nsanitize the output of the Git command, replacing (via `sed`) the\nactual emitted path with some placeholder, such as \"%HOME%\" or\nsomething, and then have the tests look for (`grep` or whatnot)\nneedles using that literal placeholder rather than trying to perfectly\nmatch the path emitted by Git. This approach makes sense since these\ntests are about overall functionality of git-maintenance, not about\nthe specific path in which the person happens to be running the tests.\n"},{"id":"518802","messageId":"xmqqsekvvz1t.fsf@gitster.g","threadId":"63510","inReplyTo":"CAPig+cRpS=t-wNLxdV_WoKF0Wzy-S1oLUEyS18S9r-4OBQ87VQ@mail.gmail.com","subject":"Re: [PATCH] t7900: use pwd -P in macOS maintenance test","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-05-23T20:42:54Z","receivedAt":"2025-05-23T20:42:57Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eric Sunshine <sunshine@sunshineco.com> writes:\n\n>> -       pfx=$(cd \"$HOME\" && pwd) &&\n>> +       pfx=$(cd \"$HOME\" && pwd -P) &&\n>\n> Okay, this seems like the minimum fix[*], and -P is POSIX.\n>\n> However, have you tested this on Windows? I ask because, despite the\n> test's name, this and most of the tests in this script, are actually\n> run on all platforms, and because `pwd` is overridden by a shell\n> function for MinGW on Windows:\n>\n>     # t/test-lib.sh\n>     ...\n>     # git sees Windows-style pwd\n>     pwd () {\n>         builtin pwd -W\n>     }\n>\n> My quick testing suggests that this patch's change might be problematic:\n>\n>     # on Windows\n>     $ pwd\n>     /home/me\n>     $ pwd -W\n>     C:/msys64/home/me\n>     $ pwd -P\n>     /home/me\n>     $ pwd -W -P\n>     /home/me\n\nBecause pwd emulation we use on Windows ignores -P the updated\ncaller, pfx with this change would not change the existing\nbehaviour.\n\nHow would one test this situation on Windows, I wonder?  Create a\ndirectory that is pointed at by a symbolic link, and use it as the\ntest directory (either have the checkout there, or use --root to\nhave the trash directory there)?\n\n> FOOTNOTES\n>\n> [*]: In the long run, a better fix would probably be for the tests to\n> sanitize the output of the Git command, replacing (via `sed`) the\n> actual emitted path with some placeholder, such as \"%HOME%\" or\n> something, and then have the tests look for (`grep` or whatnot)\n> needles using that literal placeholder rather than trying to perfectly\n> match the path emitted by Git. This approach makes sense since these\n> tests are about overall functionality of git-maintenance, not about\n> the specific path in which the person happens to be running the tests.\n\nAnother approach may be to do a form of chdir that forces the shell\nto figure out where it really is upfront at the beginning of a test\nscript, perhaps inside test-lib.sh which happend before anything\nmeaningful happens in the test (i.e. \"cd -P .\" or something).\n"},{"id":"518803","messageId":"88e8231f-7c08-652d-f734-22c4632aa728@chromium.org","threadId":"63510","inReplyTo":"CAPig+cRpS=t-wNLxdV_WoKF0Wzy-S1oLUEyS18S9r-4OBQ87VQ@mail.gmail.com","subject":"Re: [PATCH] t7900: use pwd -P in macOS maintenance test","fromName":"Mark Mentovai","fromEmail":"mark@chromium.org","sentAt":"2025-05-23T20:43:40Z","receivedAt":"2025-05-23T20:43:50Z","isPatch":true,"sender":{"key":"mark@chromium.org","avatar":"https://avatars.githubusercontent.com/u/933273?v=4"},"body":"Eric Sunshine wrote:\n> However, have you tested this on Windows?\n\nYes, via the CI: \nhttps://github.com/markmentovai/git/actions/runs/15217563313.\n\n> I ask because, despite the\n> test's name, this and most of the tests in this script, are actually\n> run on all platforms, and because `pwd` is overridden by a shell\n> function for MinGW on Windows:\n>\n>    # t/test-lib.sh\n>    ...\n>    # git sees Windows-style pwd\n>    pwd () {\n>        builtin pwd -W\n>    }\n\nThat MinGW fallback pwd ignores arguments, so any pwd in a test regardless \nof whether it's specified as pwd or pwd -P will result in an underlying \npwd -W. The t7900 test's behavior should not change as a result of this \npatch. If it's succeeding in some MinGW environment before this patch, \nit'll continue to succeed after.\n\n> My quick testing suggests that this patch's change might be problematic:\n>\n>    # on Windows\n>    $ pwd\n>    /home/me\n>    $ pwd -W\n>    C:/msys64/home/me\n>    $ pwd -P\n>    /home/me\n>    $ pwd -W -P\n>    /home/me\n>\n> FOOTNOTES\n>\n> [*]: In the long run, a better fix would probably be for the tests to\n> sanitize the output of the Git command, replacing (via `sed`) the\n> actual emitted path with some placeholder, such as \"%HOME%\" or\n> something, and then have the tests look for (`grep` or whatnot)\n> needles using that literal placeholder rather than trying to perfectly\n> match the path emitted by Git. This approach makes sense since these\n> tests are about overall functionality of git-maintenance, not about\n> the specific path in which the person happens to be running the tests.\n\nThe specific front of the path is not important, but the tail should be as \nexpected, and I suspect that it remains much less fragile and complex to \nperform this equality comparison than it would be to try to reason about \nthe path's inner components.\n\nThe existing print-args in this test could be modified as you propose, but \nthe changes would also need to spill into the \"start and stop when several \nschedulers are available\" test later in the same file. That seems more \ninvasive and produces less clear test code than just calculating a path \nexpectation in line with what git maintenance uses in the first place.\n"},{"id":"518805","messageId":"CAPig+cQLG+zveZg73E=TiC5uShhhRXKmK5Z_M8zN3fpGNEN1ng@mail.gmail.com","threadId":"63510","inReplyTo":"xmqqsekvvz1t.fsf@gitster.g","subject":"Re: [PATCH] t7900: use pwd -P in macOS maintenance test","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2025-05-23T21:24:38Z","receivedAt":"2025-05-23T21:24:50Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Fri, May 23, 2025 at 4:42 PM Junio C Hamano <gitster@pobox.com> wrote:\n> Eric Sunshine <sunshine@sunshineco.com> writes:\n> >> -       pfx=$(cd \"$HOME\" && pwd) &&\n> >> +       pfx=$(cd \"$HOME\" && pwd -P) &&\n> >\n> > However, have you tested this on Windows? I ask because, despite the\n> > test's name, this and most of the tests in this script, are actually\n> > run on all platforms, and because `pwd` is overridden by a shell\n> > function for MinGW on Windows:\n> >\n> >     # t/test-lib.sh\n> >     ...\n> >     # git sees Windows-style pwd\n> >     pwd () {\n> >         builtin pwd -W\n> >     }\n>\n> Because pwd emulation we use on Windows ignores -P the updated\n> caller, pfx with this change would not change the existing\n> behaviour.\n\nTrue. I overlooked that[*].\n\n[*]: This is the second time in two days I made a stupid mistake when\nreplying to a patch. I should probably stop trying to read/review\npatches while my mind is more focused on whatever task I'm actually\nworking on despite having a few moments available while waiting for a\ncompilation or other lengthy operation to finish.\n\n> How would one test this situation on Windows, I wonder?  Create a\n> directory that is pointed at by a symbolic link, and use it as the\n> test directory (either have the checkout there, or use --root to\n> have the trash directory there)?\n\nPerhaps(?). The Windows experts on the list are probably better suited\nto answer.\n\n> > [*]: In the long run, a better fix would probably be for the tests to\n> > sanitize the output of the Git command, replacing (via `sed`) the\n> > actual emitted path with some placeholder, such as \"%HOME%\" or\n> > something, and then have the tests look for (`grep` or whatnot)\n> > needles using that literal placeholder rather than trying to perfectly\n> > match the path emitted by Git. This approach makes sense since these\n> > tests are about overall functionality of git-maintenance, not about\n> > the specific path in which the person happens to be running the tests.\n>\n> Another approach may be to do a form of chdir that forces the shell\n> to figure out where it really is upfront at the beginning of a test\n> script, perhaps inside test-lib.sh which happend before anything\n> meaningful happens in the test (i.e. \"cd -P .\" or something).\n\nHmm, I'm not sure how that would help this particular case which wants\nto know the path of $HOME:\n\n    pfx=$(cd \"$HOME\" && pwd -P) &&\n"},{"id":"518807","messageId":"CAPig+cQXdhT2R2_D7pYBRgCUPLtbmEK+ta+dd9EByk2i3yBkaw@mail.gmail.com","threadId":"63510","inReplyTo":"88e8231f-7c08-652d-f734-22c4632aa728@chromium.org","subject":"Re: [PATCH] t7900: use pwd -P in macOS maintenance test","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2025-05-23T21:36:34Z","receivedAt":"2025-05-23T21:36:46Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Fri, May 23, 2025 at 4:43 PM Mark Mentovai <mark@chromium.org> wrote:\n> Eric Sunshine wrote:\n> >    # t/test-lib.sh\n> >    ...\n> >    # git sees Windows-style pwd\n> >    pwd () {\n> >        builtin pwd -W\n> >    }\n>\n> That MinGW fallback pwd ignores arguments, so any pwd in a test regardless\n> of whether it's specified as pwd or pwd -P will result in an underlying\n> pwd -W. The t7900 test's behavior should not change as a result of this\n> patch. If it's succeeding in some MinGW environment before this patch,\n> it'll continue to succeed after.\n\nYou're right. I (stupidly) overlooked that the `pwd` function ignores\nits arguments.\n\n> > [*]: In the long run, a better fix would probably be for the tests to\n> > sanitize the output of the Git command, replacing (via `sed`) the\n> > actual emitted path with some placeholder, such as \"%HOME%\" or\n> > something, and then have the tests look for (`grep` or whatnot)\n> > needles using that literal placeholder rather than trying to perfectly\n> > match the path emitted by Git. This approach makes sense since these\n> > tests are about overall functionality of git-maintenance, not about\n> > the specific path in which the person happens to be running the tests.\n>\n> The specific front of the path is not important, but the tail should be as\n> expected, and I suspect that it remains much less fragile and complex to\n> perform this equality comparison than it would be to try to reason about\n> the path's inner components.\n\n`sed` in my suggestion was an afterthought. What I really had in mind\nwas perhaps augmenting the value of the GIT_TEST_MAINT_SCHEDULER\nenvironment variable, which git-maintenance already specially\nrecognizes to tweak its behavior when being run by a test, such that\nit instead emits the placeholder (literal \"%HOME%\" or whatever) as\nprefix of the path rather than the actual prefix. Tests could then\njust employ the same placeholder prefix rather than trying to exactly\nmatch the real path prefix.\n\nSuch a change is, of course, well outside the scope of the patch under\ndiscussion (hence my phrasing \"in the long run\"). The minimal fix you\npresented should be perfectly satisfactory.\n"},{"id":"518809","messageId":"xmqq7c27vvv3.fsf@gitster.g","threadId":"63510","inReplyTo":"CAPig+cQLG+zveZg73E=TiC5uShhhRXKmK5Z_M8zN3fpGNEN1ng@mail.gmail.com","subject":"Re: [PATCH] t7900: use pwd -P in macOS maintenance test","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-05-23T21:51:44Z","receivedAt":"2025-05-23T21:51:47Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eric Sunshine <sunshine@sunshineco.com> writes:\n\n> Hmm, I'm not sure how that would help this particular case which wants\n> to know the path of $HOME:\n>\n>     pfx=$(cd \"$HOME\" && pwd -P) &&\n\nWe set HOME to TRASH_DIRECTORY during test, so HOME would not be all\nthat special.\n\nI thought one of the issues was on Windows \"-P\" in \"pwd -P\" is a\nno-op?  So if you want to fix it locally perhaps\n\n    pfx=$(cd -P \"$HOME\" && pwd)\n\nbut I think the true issue may be that we set up fake HOME using\nTRASH_DIRECTORY that is before we canonicalize it with \"cd -P\".\n\nWould doing something like this (without any other changes we\ndiscussed so far) help?\n\n t/test-lib.sh | 2 ++\n 1 file changed, 2 insertions(+)\n\ndiff --git c/t/test-lib.sh w/t/test-lib.sh\nindex af722d383d..92d0db13d7 100644\n--- c/t/test-lib.sh\n+++ w/t/test-lib.sh\n@@ -1577,6 +1577,8 @@ fi\n # Use -P to resolve symlinks in our working directory so that the cwd\n # in subprocesses like git equals our $PWD (for pathname comparisons).\n cd -P \"$TRASH_DIRECTORY\" || BAIL_OUT \"cannot cd -P to \\\"$TRASH_DIRECTORY\\\"\"\n+TRASH_DIRECTORY=$(pwd)\n+HOME=\"$TRASH_DIRECTORY\"\n \n start_test_output \"$0\"\n \n\n"},{"id":"518827","messageId":"9e9ed1ce-76dc-536d-56a6-e85e1dfe58c6@chromium.org","threadId":"63510","inReplyTo":"xmqq7c27vvv3.fsf@gitster.g","subject":"Re: [PATCH] t7900: use pwd -P in macOS maintenance test","fromName":"Mark Mentovai","fromEmail":"mark@chromium.org","sentAt":"2025-05-24T04:39:20Z","receivedAt":"2025-05-24T04:39:23Z","isPatch":true,"sender":{"key":"mark@chromium.org","avatar":"https://avatars.githubusercontent.com/u/933273?v=4"},"body":"Junio C Hamano wrote:\n> Would doing something like this (without any other changes we\n> discussed so far) help?\n>\n> t/test-lib.sh | 2 ++\n> 1 file changed, 2 insertions(+)\n>\n> diff --git c/t/test-lib.sh w/t/test-lib.sh\n> index af722d383d..92d0db13d7 100644\n> --- c/t/test-lib.sh\n> +++ w/t/test-lib.sh\n> @@ -1577,6 +1577,8 @@ fi\n> # Use -P to resolve symlinks in our working directory so that the cwd\n> # in subprocesses like git equals our $PWD (for pathname comparisons).\n> cd -P \"$TRASH_DIRECTORY\" || BAIL_OUT \"cannot cd -P to \\\"$TRASH_DIRECTORY\\\"\"\n> +TRASH_DIRECTORY=$(pwd)\n> +HOME=\"$TRASH_DIRECTORY\"\n>\n>  start_test_output \"$0\"\n>\n\nThat does work as an alternate way to fix the bug that I described.\n\nForcing the entire test suite to run from a realpath-canonicalized path \nseems like a blunt instrument, though. It would tend to mask bugs that \nonly occur when git runs with a non-canonical path as its working \ndirectory. It could even mask bugs in git's own pathname canonicalization \ncode.\n"},{"id":"519011","messageId":"xmqqy0uiug1y.fsf@gitster.g","threadId":"63510","inReplyTo":"9e9ed1ce-76dc-536d-56a6-e85e1dfe58c6@chromium.org","subject":"Re: [PATCH] t7900: use pwd -P in macOS maintenance test","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-05-27T17:19:53Z","receivedAt":"2025-05-27T17:19:56Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Mark Mentovai <mark@chromium.org> writes:\n\n> Forcing the entire test suite to run from a realpath-canonicalized\n> path seems like a blunt instrument, though.\n\nI view it differently.\n\nIt is a very effective way to make sure that the tests work for one\nperson does not mysteriously break for another, only due to where\nthey kept the git repository and where in their filesystem they\narranged the tests to run.  That is not the kind of breakage we want\nour developers to be scratching their heads about.\n\nThe part of the test-lib I showed already was trying to make sure\nthat our idea of $PWD matches the physical world.  It did so only\nfor PWD, by doing 'cd -P \"$TRASH_DIRECTORY\"' early in the test setup\nsequence, but it did so after setting HOME, leaving it inconsistent\nbetween physical and logical world.\n\nWhich is the bug that my suggested fix addresses.\n\nBesides the problem we saw in this discussion thread is *not* a bug\nin Git and its normalization of its working directory, is it?  It\nwas a bug in the test script that assumed that $HOME already was\nnormalized, right?\n\nIf we want to make sure Git (not its tests, but Git itself) works\nwhen (pwd) and (pwd -P) are different, we should have a dedicated\ntest to arrange that for everybody, regardless of where the tester\nchecks out their git repository.  We can only do so on symlink\ncapable filesystems, but we do have enough support in the test\nframework to do so if you want to write such a test.\n"},{"id":"519099","messageId":"20250528201737.55268-1-mark@chromium.org","threadId":"63510","inReplyTo":"20250523193722.68344-1-mark@chromium.org","subject":"[PATCH v2] t: run tests from a normalized working directory","fromName":"Mark Mentovai","fromEmail":"mark@chromium.org","sentAt":"2025-05-28T20:17:37Z","receivedAt":"2025-05-28T20:17:39Z","isPatch":true,"sender":{"key":"mark@chromium.org","avatar":"https://avatars.githubusercontent.com/u/933273?v=4"},"body":"Some tests make git perform actions that produce observable pathnames,\nand have expectations on those paths. Tests run with $HOME set to a\n$TRASH_DIRECTORY, and with their working directory the same\n$TRASH_DIRECTORY, although these paths are logically identical, they do\nnot observe the same pathname canonicalization rules and thus might not\nbe represented by strings that compare equal. In particular, no pathname\nnormalization is applied to $TRASH_DIRECTORY or $HOME, while tests\nchange their working directory with `cd -P`, which normalizes the\nworking directory's path by fully resolving symbolic links.\n\nt7900's macOS maintenance tests (which are not limited to running on\nmacOS) have an expectation on a path that `git maintenance` forms by\nusing abspath.c strbuf_realpath() to resolve a canonical absolute path\nbased on $HOME. When t7900 runs from a working directory that contains\nsymbolic links in its pathname, $HOME will also contain symbolic links,\nwhich `git maintenance` resolves but the test's expectation does not,\ncausing a test failure.\n\nAlign $TRASH_DIRECTORY and $HOME with the normalized path as used for\nthe working directory by resetting them to match the working directory\nafter it's established by `cd -P`. With all paths in agreement and\nsymbolic links resolved, pathname expectations can be set and met based\non string comparison without regard to external environmental factors\nsuch as the presence of symbolic links in a path.\n\nSuggested-by: Junio C Hamano <gitster@pobox.com>\nSigned-off-by: Mark Mentovai <mark@chromium.org>\n---\n t/test-lib.sh | 2 ++\n 1 file changed, 2 insertions(+)\n\ndiff --git a/t/test-lib.sh b/t/test-lib.sh\nindex af722d383d9b..92d0db13d742 100644\n--- a/t/test-lib.sh\n+++ b/t/test-lib.sh\n@@ -1577,6 +1577,8 @@ fi\n # Use -P to resolve symlinks in our working directory so that the cwd\n # in subprocesses like git equals our $PWD (for pathname comparisons).\n cd -P \"$TRASH_DIRECTORY\" || BAIL_OUT \"cannot cd -P to \\\"$TRASH_DIRECTORY\\\"\"\n+TRASH_DIRECTORY=$(pwd)\n+HOME=\"$TRASH_DIRECTORY\"\n \n start_test_output \"$0\"\n \n\nRange-diff against v1:\n1:  95491c294c1e ! 1:  496e490a6462 t7900: use pwd -P in macOS maintenance test\n    @@ Metadata\n     Author: Mark Mentovai <mark@chromium.org>\n     \n      ## Commit message ##\n    -    t7900: use pwd -P in macOS maintenance test\n    +    t: run tests from a normalized working directory\n     \n    -    $pfx is the basis for the expectation that launchd plist paths formed by\n    -    `git maintenance start` will be compared against. These paths are formed\n    -    in `git maintenance` by builtin/gc.c launchctl_service_filename(), which\n    -    calls path.c interpolate_path() with real_home = 1, causing abspath.c\n    -    strbuf_realpath() to resolve a canonical absolute path. Since $pfx is\n    -    not determined according to the same realpath semantics, when t7900 is\n    -    run from a working directory that contains a symbolic link in its path,\n    -    the realpath operation will produce a different path than $pfx contains,\n    -    although both paths logically reference the same directory. The test\n    -    fails in this case.\n    +    Some tests make git perform actions that produce observable pathnames,\n    +    and have expectations on those paths. Tests run with $HOME set to a\n    +    $TRASH_DIRECTORY, and with their working directory the same\n    +    $TRASH_DIRECTORY, although these paths are logically identical, they do\n    +    not observe the same pathname canonicalization rules and thus might not\n    +    be represented by strings that compare equal. In particular, no pathname\n    +    normalization is applied to $TRASH_DIRECTORY or $HOME, while tests\n    +    change their working directory with `cd -P`, which normalizes the\n    +    working directory's path by fully resolving symbolic links.\n     \n    -    Base $pfx on the physical working directory (pwd -P), with all symbolic\n    -    links fully resolved, so that the path that the test expects matches\n    -    what `git maintenance` generates, even when running from a working\n    -    directory whose path contains a symbolic link.\n    +    t7900's macOS maintenance tests (which are not limited to running on\n    +    macOS) have an expectation on a path that `git maintenance` forms by\n    +    using abspath.c strbuf_realpath() to resolve a canonical absolute path\n    +    based on $HOME. When t7900 runs from a working directory that contains\n    +    symbolic links in its pathname, $HOME will also contain symbolic links,\n    +    which `git maintenance` resolves but the test's expectation does not,\n    +    causing a test failure.\n     \n    +    Align $TRASH_DIRECTORY and $HOME with the normalized path as used for\n    +    the working directory by resetting them to match the working directory\n    +    after it's established by `cd -P`. With all paths in agreement and\n    +    symbolic links resolved, pathname expectations can be set and met based\n    +    on string comparison without regard to external environmental factors\n    +    such as the presence of symbolic links in a path.\n    +\n    +    Suggested-by: Junio C Hamano <gitster@pobox.com>\n         Signed-off-by: Mark Mentovai <mark@chromium.org>\n     \n    - ## t/t7900-maintenance.sh ##\n    -@@ t/t7900-maintenance.sh: test_expect_success 'stop preserves surrounding schedule' '\n    + ## t/test-lib.sh ##\n    +@@ t/test-lib.sh: fi\n    + # Use -P to resolve symlinks in our working directory so that the cwd\n    + # in subprocesses like git equals our $PWD (for pathname comparisons).\n    + cd -P \"$TRASH_DIRECTORY\" || BAIL_OUT \"cannot cd -P to \\\"$TRASH_DIRECTORY\\\"\"\n    ++TRASH_DIRECTORY=$(pwd)\n    ++HOME=\"$TRASH_DIRECTORY\"\n      \n    - test_expect_success 'start and stop macOS maintenance' '\n    - \t# ensure $HOME can be compared against hook arguments on all platforms\n    --\tpfx=$(cd \"$HOME\" && pwd) &&\n    -+\tpfx=$(cd \"$HOME\" && pwd -P) &&\n    + start_test_output \"$0\"\n      \n    - \twrite_script print-args <<-\\EOF &&\n    - \techo $* | sed \"s:gui/[0-9][0-9]*:gui/[UID]:\" >>args\n-- \n2.49.0\n\n"},{"id":"519113","messageId":"20250528230804.GA16856@tb-raspi4","threadId":"63510","inReplyTo":"20250528201737.55268-1-mark@chromium.org","subject":"Re: [PATCH v2] t: run tests from a normalized working directory","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2025-05-28T23:08:04Z","receivedAt":"2025-05-28T23:08:17Z","isPatch":true,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On Wed, May 28, 2025 at 04:17:37PM -0400, Mark Mentovai wrote:\n\nThe problem is well described, thanks for that.\nHowever, different words and terms are used for the same thing:\n  \"normalized working directory\" (which is easy to confuse\n    with normalized working tree where CRLF-LF conversion had been\n    done and clean filters applied.\n  \"pathname canonicalization\"\n  \"canonical absolute path\"\n  \"normalized path\"\n... and that is done in \"strbuf_realpath()\"\n\nMay be the word normalized can be replaced here ?\nStarting with the head line, how about this:\nt: run tests from an absolute path\n\nAnd later in the text:\nuse \"absolute path\" instead of \"normalized path\" ?\n\n> Some tests make git perform actions that produce observable pathnames,\n> and have expectations on those paths. Tests run with $HOME set to a\n> $TRASH_DIRECTORY, and with their working directory the same\n> $TRASH_DIRECTORY, although these paths are logically identical, they do\n> not observe the same pathname canonicalization rules and thus might not\n> be represented by strings that compare equal. In particular, no pathname\n> normalization is applied to $TRASH_DIRECTORY or $HOME, while tests\n> change their working directory with `cd -P`, which normalizes the\n> working directory's path by fully resolving symbolic links.\n> \n> t7900's macOS maintenance tests (which are not limited to running on\n> macOS) have an expectation on a path that `git maintenance` forms by\n> using abspath.c strbuf_realpath() to resolve a canonical absolute path\n> based on $HOME. When t7900 runs from a working directory that contains\n> symbolic links in its pathname, $HOME will also contain symbolic links,\n> which `git maintenance` resolves but the test's expectation does not,\n> causing a test failure.\n> \n> Align $TRASH_DIRECTORY and $HOME with the normalized path as used for\n> the working directory by resetting them to match the working directory\n> after it's established by `cd -P`. With all paths in agreement and\n> symbolic links resolved, pathname expectations can be set and met based\n> on string comparison without regard to external environmental factors\n> such as the presence of symbolic links in a path.\n> \n> Suggested-by: Junio C Hamano <gitster@pobox.com>\n> Signed-off-by: Mark Mentovai <mark@chromium.org>\n> ---\n>  t/test-lib.sh | 2 ++\n>  1 file changed, 2 insertions(+)\n> \n> diff --git a/t/test-lib.sh b/t/test-lib.sh\n> index af722d383d9b..92d0db13d742 100644\n> --- a/t/test-lib.sh\n> +++ b/t/test-lib.sh\n> @@ -1577,6 +1577,8 @@ fi\n>  # Use -P to resolve symlinks in our working directory so that the cwd\n>  # in subprocesses like git equals our $PWD (for pathname comparisons).\n>  cd -P \"$TRASH_DIRECTORY\" || BAIL_OUT \"cannot cd -P to \\\"$TRASH_DIRECTORY\\\"\"\n> +TRASH_DIRECTORY=$(pwd)\n> +HOME=\"$TRASH_DIRECTORY\"\n>  \n>  start_test_output \"$0\"\n>  \n> \n"},{"id":"519199","messageId":"xmqqfrgmhep3.fsf@gitster.g","threadId":"63510","inReplyTo":"20250528230804.GA16856@tb-raspi4","subject":"Re: [PATCH v2] t: run tests from a normalized working directory","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-05-30T05:04:24Z","receivedAt":"2025-05-30T05:04:27Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Torsten Bögershausen <tboegi@web.de> writes:\n\n> On Wed, May 28, 2025 at 04:17:37PM -0400, Mark Mentovai wrote:\n>\n> The problem is well described, thanks for that.\n> However, different words and terms are used for the same thing:\n>   \"normalized working directory\" (which is easy to confuse\n>     with normalized working tree where CRLF-LF conversion had been\n>     done and clean filters applied.\n>   \"pathname canonicalization\"\n>   \"canonical absolute path\"\n>   \"normalized path\"\n> ... and that is done in \"strbuf_realpath()\"\n>\n> May be the word normalized can be replaced here ?\n> Starting with the head line, how about this:\n> t: run tests from an absolute path\n>\n> And later in the text:\n> use \"absolute path\" instead of \"normalized path\" ?\n\nThanks for a careful reading.  When I read the log message for the\nfirst time, it did not bother me too much that it said canonicalize\nand normalize interchangeably, and the two verbs still do not bother\nme terribly.  I agree with you that clearly describing what the\ncanonicalization rules do (i.e. fully resolving symbolic links to\nmake the path absolute) very good idea, but I think the last\nsentence of the first paragraph does a good job at it already.\n\nCan you offer a rewrite along the lines you suggest so that we can\ncompare?  I personally felt that what Mark gave us, albeit a bit on\nthe more verbose and repetitive side, were written clearly enough.\n\nThanks.\n\n>> Some tests make git perform actions that produce observable pathnames,\n>> and have expectations on those paths. Tests run with $HOME set to a\n>> $TRASH_DIRECTORY, and with their working directory the same\n>> $TRASH_DIRECTORY, although these paths are logically identical, they do\n>> not observe the same pathname canonicalization rules and thus might not\n>> be represented by strings that compare equal. In particular, no pathname\n>> normalization is applied to $TRASH_DIRECTORY or $HOME, while tests\n>> change their working directory with `cd -P`, which normalizes the\n>> working directory's path by fully resolving symbolic links.\n>>\n>> t7900's macOS maintenance tests (which are not limited to running on\n>> macOS) have an expectation on a path that `git maintenance` forms by\n>> using abspath.c strbuf_realpath() to resolve a canonical absolute path\n>> based on $HOME. When t7900 runs from a working directory that contains\n>> symbolic links in its pathname, $HOME will also contain symbolic links,\n>> which `git maintenance` resolves but the test's expectation does not,\n>> causing a test failure.\n>> \n>> Align $TRASH_DIRECTORY and $HOME with the normalized path as used for\n>> the working directory by resetting them to match the working directory\n>> after it's established by `cd -P`. With all paths in agreement and\n>> symbolic links resolved, pathname expectations can be set and met based\n>> on string comparison without regard to external environmental factors\n>> such as the presence of symbolic links in a path.\n>> \n>> Suggested-by: Junio C Hamano <gitster@pobox.com>\n>> Signed-off-by: Mark Mentovai <mark@chromium.org>\n>> ---\n>>  t/test-lib.sh | 2 ++\n>>  1 file changed, 2 insertions(+)\n>> \n>> diff --git a/t/test-lib.sh b/t/test-lib.sh\n>> index af722d383d9b..92d0db13d742 100644\n>> --- a/t/test-lib.sh\n>> +++ b/t/test-lib.sh\n>> @@ -1577,6 +1577,8 @@ fi\n>>  # Use -P to resolve symlinks in our working directory so that the cwd\n>>  # in subprocesses like git equals our $PWD (for pathname comparisons).\n>>  cd -P \"$TRASH_DIRECTORY\" || BAIL_OUT \"cannot cd -P to \\\"$TRASH_DIRECTORY\\\"\"\n>> +TRASH_DIRECTORY=$(pwd)\n>> +HOME=\"$TRASH_DIRECTORY\"\n>>  \n>>  start_test_output \"$0\"\n>>  \n>> \n"},{"id":"519304","messageId":"20250531054618.GA30443@tb-raspi4","threadId":"63510","inReplyTo":"xmqqfrgmhep3.fsf@gitster.g","subject":"Re: [PATCH v2] t: run tests from a normalized working directory","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2025-05-31T05:46:18Z","receivedAt":"2025-05-31T05:46:29Z","isPatch":true,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On Thu, May 29, 2025 at 10:04:24PM -0700, Junio C Hamano wrote:\n> Torsten Bögershausen <tboegi@web.de> writes:\n> \n> > On Wed, May 28, 2025 at 04:17:37PM -0400, Mark Mentovai wrote:\n> >\n> > The problem is well described, thanks for that.\n> > However, different words and terms are used for the same thing:\n> >   \"normalized working directory\" (which is easy to confuse\n> >     with normalized working tree where CRLF-LF conversion had been\n> >     done and clean filters applied.\n> >   \"pathname canonicalization\"\n> >   \"canonical absolute path\"\n> >   \"normalized path\"\n> > ... and that is done in \"strbuf_realpath()\"\n> >\n> > May be the word normalized can be replaced here ?\n> > Starting with the head line, how about this:\n> > t: run tests from an absolute path\n> >\n> > And later in the text:\n> > use \"absolute path\" instead of \"normalized path\" ?\n> \n> Thanks for a careful reading.  When I read the log message for the\n> first time, it did not bother me too much that it said canonicalize\n> and normalize interchangeably, and the two verbs still do not bother\n> me terribly.  I agree with you that clearly describing what the\n> canonicalization rules do (i.e. fully resolving symbolic links to\n> make the path absolute) very good idea, but I think the last\n> sentence of the first paragraph does a good job at it already.\n> \n> Can you offer a rewrite along the lines you suggest so that we can\n> compare?  I personally felt that what Mark gave us, albeit a bit on\n> the more verbose and repetitive side, were written clearly enough.\n> \n> Thanks.\n\nHere is an attempt to do so.\nThe word canonical has been removed.\nAfter reading the help for\n'pwd -P' and 'cd -P'\n\"absolute\" is replaced by \"physical\".\nA matter of taste.\nIf absolute is more used here in Git, I am fine with any.\n\n==================================================\nt: run 7900 tests from the physical working directory\n\nSome tests make git perform actions that produce observable pathnames,\nand have expectations on those paths. Tests run with $HOME set to a\n$TRASH_DIRECTORY, and with their working directory the same\n$TRASH_DIRECTORY, although these paths are physical identical, they do\nnot observe the same pathname normalization rules and thus might not\nbe represented by strings that compare equal. In particular, no pathname\nnormalization is applied to $TRASH_DIRECTORY or $HOME, while tests\nchange their working directory with `cd -P` which resolves symbolic links\nreturning the physical path.\n\nt7900's macOS maintenance tests (which are not limited to running on\nmacOS) have an expectation on a path that `git maintenance` forms by\nusing abspath.c strbuf_realpath() to resolve the physical path\nbased on $HOME. When t7900 runs from a working directory that contains\nsymbolic links in its pathname, $HOME will also contain symbolic links,\nwhich `git maintenance` resolves but the test's expectation does not,\ncausing a test failure.\n\nAlign $TRASH_DIRECTORY and $HOME with the physical path as used for\nthe working directory by resetting them to match the working directory\nafter it's established by `cd -P`. With all paths in agreement and\nsymbolic links resolved, pathname expectations can be set and met based\non string comparison without regard to external environmental factors\nsuch as the presence of symbolic links in a path.\n"},{"id":"519350","messageId":"xmqqcybnxvr2.fsf@gitster.g","threadId":"63510","inReplyTo":"20250531054618.GA30443@tb-raspi4","subject":"Re: [PATCH v2] t: run tests from a normalized working directory","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-06-01T16:38:25Z","receivedAt":"2025-06-01T16:38:27Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Torsten Bögershausen <tboegi@web.de> writes:\n\n> The word canonical has been removed.\n> After reading the help for\n> 'pwd -P' and 'cd -P'\n> \"absolute\" is replaced by \"physical\".\n> A matter of taste.\n> If absolute is more used here in Git, I am fine with any.\n\nIt is OK as long as we are locally consistent.  I do think inside\nour codebase it seems we use \"absolute\" more, but the change in\nquestion is about use of \"-P\" option, which certainly was taken from\n\"physical\", in our test scripts, so I am OK with your description\nbelow to use that word.\n\nIf somebody really cared (and I don't), we may want to pick a single\nword among physical, absolute, and real, but the only thing is that\nwe are using them interchangeably, so as long as we make it clear\n(e.g. perhaps strbuf_realpath() and the underlying helper functions\nthat are used by it may have a comment or two that says that we use\nthese three words interchangeably to our developers), it would be\ngood enough.\n\n> ==================================================\n> t: run 7900 tests from the physical working directory\n>\n> Some tests make git perform actions that produce observable pathnames,\n> and have expectations on those paths. Tests run with $HOME set to a\n> $TRASH_DIRECTORY, and with their working directory the same\n> $TRASH_DIRECTORY, although these paths are physical identical, they do\n> not observe the same pathname normalization rules and thus might not\n> be represented by strings that compare equal.\n> In particular, no pathname\n> normalization is applied to $TRASH_DIRECTORY or $HOME, while tests\n> change their working directory with `cd -P` which resolves symbolic links\n> returning the physical path.\n\n\"physical identical\"?  I think the problem is $HOME and $TRASH are\nthe same but not physically normalized, which means \"cd $HOME &&\npwd\", \"cd $HOME && pwd -P\" and \"cd -P $HOME && pwd\" can give\ndifferent results from these two variables.  How about replacing the\nlatter half of the above with something much simpler, like this?\n\n    ... although HOME and TRASH_DIRECTORY have identical values, the\n    physical path to it (i.e. what \"cd $HOME && pwd -P\" reports) may\n    be different.\n\n> t7900's macOS maintenance tests (which are not limited to running on\n> macOS) have an expectation on a path that `git maintenance` forms by\n> using abspath.c strbuf_realpath() to resolve the physical path\n> based on $HOME. When t7900 runs from a working directory that contains\n> symbolic links in its pathname, $HOME will also contain symbolic links,\n> which `git maintenance` resolves but the test's expectation does not,\n> causing a test failure.\n>\n> Align $TRASH_DIRECTORY and $HOME with the physical path as used for\n> the working directory by resetting them to match the working directory\n> after it's established by `cd -P`. With all paths in agreement and\n> symbolic links resolved, pathname expectations can be set and met based\n> on string comparison without regard to external environmental factors\n> such as the presence of symbolic links in a path.\n"},{"id":"519481","messageId":"f0d4c85a-b833-c52d-b54f-77ab81f22451@chromium.org","threadId":"63510","inReplyTo":"xmqqcybnxvr2.fsf@gitster.g","subject":"Re: [PATCH v2] t: run tests from a normalized working directory","fromName":"Mark Mentovai","fromEmail":"mark@chromium.org","sentAt":"2025-06-02T16:08:05Z","receivedAt":"2025-06-02T16:08:07Z","isPatch":true,"sender":{"key":"mark@chromium.org","avatar":"https://avatars.githubusercontent.com/u/933273?v=4"},"body":"Junio C Hamano wrote:\n> Torsten Bögershausen <tboegi@web.de> writes:\n>\n>> The word canonical has been removed.\n>> After reading the help for\n>> 'pwd -P' and 'cd -P'\n>> \"absolute\" is replaced by \"physical\".\n>> A matter of taste.\n>> If absolute is more used here in Git, I am fine with any.\n>\n> It is OK as long as we are locally consistent.  I do think inside\n> our codebase it seems we use \"absolute\" more, but the change in\n> question is about use of \"-P\" option, which certainly was taken from\n> \"physical\", in our test scripts, so I am OK with your description\n> below to use that word.\n>\n> If somebody really cared (and I don't), we may want to pick a single\n> word among physical, absolute, and real, but the only thing is that\n> we are using them interchangeably, so as long as we make it clear\n> (e.g. perhaps strbuf_realpath() and the underlying helper functions\n> that are used by it may have a comment or two that says that we use\n> these three words interchangeably to our developers), it would be\n> good enough.\n\nAn \"absolute\" path is well-defined and commonly understood to have a \nsingular meaning. These paths are relative to the root directory, and are \nidentified by a leading separator (/). POSIX specifies this at XBD.3.2[1] \nand XBD.4.16[2].\n\nThis change is not concerned with absolute paths. All of the paths in \nquestion are absolute, both before and after this change.\n\nThere is no single term that's widely understood to have the meaning that \nthis change is concerned with. \"Physical\" is a contender, but this term is \nnot broadly understood without providing additional context. In fact, \nwhile \"physical\" is the namesake for the pwd's `-P` option, the POSIX \ndefinition of pwd(1) doesn't even use this term, instead explaining the \nconcept fully in prose[3]. I don't believe it's appropriate to discuss \n\"physical\" paths without an introduction clarifying its intended meaning.\n\n`realpath` is a library interface that transforms paths to those having \nthe semantics at issue, but it's somewhat obscure, and easily confused \nwith \"real path\" whose meaning would be entirely ambiguous. realpath(3) \ndocumentation from POSIX[4] explains the semantics fully; glibc[5], and \nLinux man-pages[6] provide full explanation while also using the term \n\"canonicalize\".\n\n\"Canonicalize\" alone is too generic, because there are several axes of \ncanonicalization that may apply to a path, some filesystem-dependent. This \nchange is concerned with canonicalization via symbolic link resolution, \nbut in other contexts, path canonicalization may refer to other concepts, \nsuch as case matching on case-preserving filesystems, or encoding \ncanonicalization (such as Unicode normalization) on filesystems that have \ndefined encoding rules.\n\nAll of this illustrates the difficulty in choosing a single term to \nunambiguously convey the meaning. I chose to write a commit message that \nfavored technical precision, even if it meant tending toward what Junio \ncalled \"the more verbose and repetitive side\". I believed that to be \nnecessary to fully explain the background, the problem, and the solution.\n\nI don't know that this amount of scrutiny of a commit message that's \nprecise and correct is entirely justified, but if there's a strong \npreference to converge on a single term, provided that it's not \ntechnically inaccurate, I'll accede to the request. I don't expect that it \nwill shrink the amount of explanatory text, though, because as I've \nillustrated, there isn't really a term in existence that conveys this \nprinciple generally in a way that's suitable for broad understanding.\n\n[1] https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap03.html#tag_03_02\n[2] https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap04.html#tag_04_16\n[3] https://pubs.opengroup.org/onlinepubs/9799919799/utilities/pwd.html\n[4] https://pubs.opengroup.org/onlinepubs/9699919799/functions/realpath.html\n[5] https://sourceware.org/glibc/manual/2.41/html_node/Symbolic-Links.html#index-realpath\n[6] https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/man/man3/realpath.3\n\n>> ==================================================\n>> t: run 7900 tests from the physical working directory\n>>\n>> Some tests make git perform actions that produce observable pathnames,\n>> and have expectations on those paths. Tests run with $HOME set to a\n>> $TRASH_DIRECTORY, and with their working directory the same\n>> $TRASH_DIRECTORY, although these paths are physical identical, they do\n>> not observe the same pathname normalization rules and thus might not\n>> be represented by strings that compare equal.\n>> In particular, no pathname\n>> normalization is applied to $TRASH_DIRECTORY or $HOME, while tests\n>> change their working directory with `cd -P` which resolves symbolic links\n>> returning the physical path.\n>\n> \"physical identical\"?  I think the problem is $HOME and $TRASH are\n> the same but not physically normalized, which means \"cd $HOME &&\n> pwd\", \"cd $HOME && pwd -P\" and \"cd -P $HOME && pwd\" can give\n> different results from these two variables.  How about replacing the\n> latter half of the above with something much simpler, like this?\n>\n>    ... although HOME and TRASH_DIRECTORY have identical values, the\n>    physical path to it (i.e. what \"cd $HOME && pwd -P\" reports) may\n>    be different.\n>\n>> t7900's macOS maintenance tests (which are not limited to running on\n>> macOS) have an expectation on a path that `git maintenance` forms by\n>> using abspath.c strbuf_realpath() to resolve the physical path\n>> based on $HOME. When t7900 runs from a working directory that contains\n>> symbolic links in its pathname, $HOME will also contain symbolic links,\n>> which `git maintenance` resolves but the test's expectation does not,\n>> causing a test failure.\n>>\n>> Align $TRASH_DIRECTORY and $HOME with the physical path as used for\n>> the working directory by resetting them to match the working directory\n>> after it's established by `cd -P`. With all paths in agreement and\n>> symbolic links resolved, pathname expectations can be set and met based\n>> on string comparison without regard to external environmental factors\n>> such as the presence of symbolic links in a path.\n>\n"},{"id":"519508","messageId":"xmqqy0u9subw.fsf@gitster.g","threadId":"63510","inReplyTo":"f0d4c85a-b833-c52d-b54f-77ab81f22451@chromium.org","subject":"Re: [PATCH v2] t: run tests from a normalized working directory","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-06-02T21:32:35Z","receivedAt":"2025-06-02T21:32:38Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Mark Mentovai <mark@chromium.org> writes:\n\n> `realpath` is a library interface that transforms paths to those\n> having the semantics at issue, but it's somewhat obscure, and easily\n> confused with \"real path\" whose meaning would be entirely\n> ambiguous. realpath(3) documentation from POSIX[4] explains the\n> semantics fully; glibc[5], and Linux man-pages[6] provide full\n> explanation while also using the term \"canonicalize\".\n>\n> \"Canonicalize\" alone is too generic, because there are several axes of\n\nYes.  You need to specify what you are canonicalizing to, and once\nyou are going to do so, there is no need for that heavy verb, i.e.\nyou do not need to say \"canonicalize it to realpath\"---you say \"turn\nit into realpath\" and you convey what you want to say just fine.\n\n> All of this illustrates the difficulty in choosing a single term to\n> unambiguously convey the meaning. I chose to write a commit message\n> that favored technical precision, even if it meant tending toward what\n> Junio called \"the more verbose and repetitive side\". I believed that\n> to be necessary to fully explain the background, the problem, and the\n> solution.\n\nYup, that is why I said I thought your original was clear enough.\n\nI am tempted to say that we take what we have from you and merge it\ndown.\n"},{"id":"519533","messageId":"20250603050256.GA9449@tb-raspi4","threadId":"63510","inReplyTo":"xmqqy0u9subw.fsf@gitster.g","subject":"Re: [PATCH v2] t: run tests from a normalized working directory","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2025-06-03T05:02:56Z","receivedAt":"2025-06-03T05:03:05Z","isPatch":true,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On Mon, Jun 02, 2025 at 02:32:35PM -0700, Junio C Hamano wrote:\n> Mark Mentovai <mark@chromium.org> writes:\n> \n> > `realpath` is a library interface that transforms paths to those\n> > having the semantics at issue, but it's somewhat obscure, and easily\n> > confused with \"real path\" whose meaning would be entirely\n> > ambiguous. realpath(3) documentation from POSIX[4] explains the\n> > semantics fully; glibc[5], and Linux man-pages[6] provide full\n> > explanation while also using the term \"canonicalize\".\n> >\n> > \"Canonicalize\" alone is too generic, because there are several axes of\n> \n> Yes.  You need to specify what you are canonicalizing to, and once\n> you are going to do so, there is no need for that heavy verb, i.e.\n> you do not need to say \"canonicalize it to realpath\"---you say \"turn\n> it into realpath\" and you convey what you want to say just fine.\n> \n> > All of this illustrates the difficulty in choosing a single term to\n> > unambiguously convey the meaning. I chose to write a commit message\n> > that favored technical precision, even if it meant tending toward what\n> > Junio called \"the more verbose and repetitive side\". I believed that\n> > to be necessary to fully explain the background, the problem, and the\n> > solution.\n> \n> Yup, that is why I said I thought your original was clear enough.\n> \n> I am tempted to say that we take what we have from you and merge it\n> down.\n> \n\nThanks for the long explanations.\nI still stumble across the headline:\nt: run tests from a normalized working directory\n\nRe-reading the help for realpath() and pwd, would this makes sense:\nt: run tests from an absolute pathname\n"},{"id":"519549","messageId":"08b9b990-9ddc-740e-99ab-82d09fb30ef3@chromium.org","threadId":"63510","inReplyTo":"20250603050256.GA9449@tb-raspi4","subject":"Re: [PATCH v2] t: run tests from a normalized working directory","fromName":"Mark Mentovai","fromEmail":"mark@chromium.org","sentAt":"2025-06-03T13:15:54Z","receivedAt":"2025-06-03T13:16:03Z","isPatch":true,"sender":{"key":"mark@chromium.org","avatar":"https://avatars.githubusercontent.com/u/933273?v=4"},"body":"Torsten Bögershausen wrote:\n> On Mon, Jun 02, 2025 at 02:32:35PM -0700, Junio C Hamano wrote:\n>> Mark Mentovai <mark@chromium.org> writes:\n>>\n>>> `realpath` is a library interface that transforms paths to those\n>>> having the semantics at issue, but it's somewhat obscure, and easily\n>>> confused with \"real path\" whose meaning would be entirely\n>>> ambiguous. realpath(3) documentation from POSIX[4] explains the\n>>> semantics fully; glibc[5], and Linux man-pages[6] provide full\n>>> explanation while also using the term \"canonicalize\".\n>>>\n>>> \"Canonicalize\" alone is too generic, because there are several axes of\n>>\n>> Yes.  You need to specify what you are canonicalizing to, and once\n>> you are going to do so, there is no need for that heavy verb, i.e.\n>> you do not need to say \"canonicalize it to realpath\"---you say \"turn\n>> it into realpath\" and you convey what you want to say just fine.\n>>\n>>> All of this illustrates the difficulty in choosing a single term to\n>>> unambiguously convey the meaning. I chose to write a commit message\n>>> that favored technical precision, even if it meant tending toward what\n>>> Junio called \"the more verbose and repetitive side\". I believed that\n>>> to be necessary to fully explain the background, the problem, and the\n>>> solution.\n>>\n>> Yup, that is why I said I thought your original was clear enough.\n>>\n>> I am tempted to say that we take what we have from you and merge it\n>> down.\n>>\n>\n> Thanks for the long explanations.\n> I still stumble across the headline:\n> t: run tests from a normalized working directory\n>\n> Re-reading the help for realpath() and pwd, would this makes sense:\n> t: run tests from an absolute pathname\n\nNo. As I wrote earlier:\n\n> An \"absolute\" path is well-defined and commonly understood to have a\n> singular meaning. These paths are relative to the root directory, and are \n> identified by a leading separator (/). POSIX specifies this at XBD.3.2[1] \n> and XBD.4.16[2].\n>\n> This change is not concerned with absolute paths. All of the paths in\n> question are absolute, both before and after this change.\n[...]\n> [1] https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap03.html#tag_03_02\n> [2] https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap04.html#tag_04_16\n\nMaking a path absolute is a different transformation than what is at issue \nhere. You may have been misled by the fact that pwd -P and realpath both \nmake paths absolute in addition to performing symbolic link resolution. \nThe latter is what's operative here.\n\nAs I've explained, the paths in question are already absolute in git's \ntest suite today, even without the proposed change. It's not correct to \nsummarize the change as making paths absolute, when that's neither \nchanging nor the crux of the problem.\n"},{"id":"519584","messageId":"xmqq4iwwk7mc.fsf@gitster.g","threadId":"63510","inReplyTo":"08b9b990-9ddc-740e-99ab-82d09fb30ef3@chromium.org","subject":"Re: [PATCH v2] t: run tests from a normalized working directory","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-06-03T18:22:35Z","receivedAt":"2025-06-03T18:22:37Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Mark Mentovai <mark@chromium.org> writes:\n\n> Torsten Bögershausen wrote:\n>> On Mon, Jun 02, 2025 at 02:32:35PM -0700, Junio C Hamano wrote:\n>>> ...\n>>> Yes.  You need to specify what you are canonicalizing to, and once\n>>> you are going to do so, there is no need for that heavy verb, i.e.\n>>> you do not need to say \"canonicalize it to realpath\"---you say \"turn\n>>> it into realpath\" and you convey what you want to say just fine.\n>>>\n>> Re-reading the help for realpath() and pwd, would this makes sense:\n>> t: run tests from an absolute pathname\n> ...\n> Making a path absolute is a different transformation than what is at\n> issue here. You may have been misled by the fact that pwd -P and\n> realpath both make paths absolute in addition to performing symbolic\n> link resolution. The latter is what's operative here.\n>\n> As I've explained, the paths in question are already absolute in git's\n> test suite today, even without the proposed change. It's not correct\n> to summarize the change as making paths absolute, when that's neither\n> changing nor the crux of the problem.\n\nAbsolutely ;-)\n\n\"normalized\" does invite \"normalize to what standard\" question, but\nas you mentioned in an earlier post, \"realpath\" is a bit dense for\nthose who don't read realpath(3) manual pages, and \"symlink-resolved\nfile path\" is quite mouthful even though it might be understandable.\n\nLet me merge it down with the commit title as-is and then cook it in\n'next' during the -rc period.\n\nThanks.\n"}]}