{"thread":{"id":"64239","subject":"[PATCH 0/5] gitlab-ci: some fixes for failures on Windows","startedAt":"2025-10-02T11:04:48Z","lastAt":"2025-10-06T10:21:00Z","messageCount":10,"participants":["Patrick Steinhardt","Kristoffer Haugsbakk","Toon Claes"],"isPatch":true,"patchVersion":1,"patchTotal":5},"messages":[{"id":"527781","messageId":"20251002-pks-gitlab-ci-windows-improvements-v1-0-6a8b6b45d728@pks.im","threadId":"64239","inReplyTo":null,"subject":"[PATCH 0/5] gitlab-ci: some fixes for failures on Windows","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-10-02T11:04:35Z","receivedAt":"2025-10-02T11:04:48Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"Hi,\n\nthis small patch series fixes some intermittent failures we have\nobserved with our Windows CI runners. Furthermore, it fixes one\npersistent test failure in one of the Windows runners that was\nintroduced recently via tests for git-last-modified(1).\n\nThe pipeline at [1] shows that tests succeed now.\n\nThanks!\n\nPatrick\n\n[1]: https://gitlab.com/gitlab-org/git/-/merge_requests/426\n\n---\nPatrick Steinhardt (5):\n      gitlab-ci: dedup instructions to disable realtime monitoring\n      gitlab-ci: ignore failures to disable realtime monitoring\n      gitlab-ci: drop workaround for Python certificate store on Windows\n      gitlab-ci: upload Meson test logs as JUnit reports\n      t8020: fix test failure due to indeterministic tag sorting\n\n .gitlab-ci.yml           | 29 +++++++++++++++++------------\n t/t8020-last-modified.sh | 34 +++++++++++++++++++---------------\n 2 files changed, 36 insertions(+), 27 deletions(-)\n\n\n---\nbase-commit: 821f583da6d30a84249f75f33501504d597bc16b\nchange-id: 20251001-pks-gitlab-ci-windows-improvements-16dd3f911688\n\n"},{"id":"527782","messageId":"20251002-pks-gitlab-ci-windows-improvements-v1-1-6a8b6b45d728@pks.im","threadId":"64239","inReplyTo":"20251002-pks-gitlab-ci-windows-improvements-v1-0-6a8b6b45d728@pks.im","subject":"[PATCH 1/5] gitlab-ci: dedup instructions to disable realtime monitoring","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-10-02T11:04:36Z","receivedAt":"2025-10-02T11:04:50Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"The instruction to disable realtime monitoring are shared across all of\nour Windows-based jobs. Deduplicate it so that we can more readily\niterate on it.\n\nSigned-off-by: Patrick Steinhardt <ps@pks.im>\n---\n .gitlab-ci.yml | 9 ++++++---\n 1 file changed, 6 insertions(+), 3 deletions(-)\n\ndiff --git a/.gitlab-ci.yml b/.gitlab-ci.yml\nindex cf122e706f..552c033fb0 100644\n--- a/.gitlab-ci.yml\n+++ b/.gitlab-ci.yml\n@@ -112,6 +112,9 @@ test:osx:\n       - t/failed-test-artifacts\n     when: on_failure\n \n+.windows_before_script: &windows_before_script\n+  - Set-MpPreference -DisableRealtimeMonitoring $true\n+\n build:mingw64:\n   stage: build\n   tags:\n@@ -119,7 +122,7 @@ build:mingw64:\n   variables:\n     NO_PERL: 1\n   before_script:\n-    - Set-MpPreference -DisableRealtimeMonitoring $true\n+    - *windows_before_script\n     - ./ci/install-sdk.ps1 -directory \"git-sdk\"\n   script:\n     - git-sdk/usr/bin/bash.exe -l -c 'ci/make-test-artifacts.sh artifacts'\n@@ -136,7 +139,7 @@ test:mingw64:\n     - job: \"build:mingw64\"\n       artifacts: true\n   before_script:\n-    - Set-MpPreference -DisableRealtimeMonitoring $true\n+    - *windows_before_script\n     - git-sdk/usr/bin/bash.exe -l -c 'tar xf artifacts/artifacts.tar.gz'\n     - New-Item -Path .git/info -ItemType Directory\n     - New-Item .git/info/exclude -ItemType File -Value \"/git-sdk\"\n@@ -150,7 +153,7 @@ test:mingw64:\n   tags:\n     - saas-windows-medium-amd64\n   before_script:\n-    - Set-MpPreference -DisableRealtimeMonitoring $true\n+    - *windows_before_script\n     - choco install -y git meson ninja openssl\n     - Import-Module $env:ChocolateyInstall\\helpers\\chocolateyProfile.psm1\n     - refreshenv\n\n-- \n2.51.0.700.g236ee7b076.dirty\n\n"},{"id":"527783","messageId":"20251002-pks-gitlab-ci-windows-improvements-v1-2-6a8b6b45d728@pks.im","threadId":"64239","inReplyTo":"20251002-pks-gitlab-ci-windows-improvements-v1-0-6a8b6b45d728@pks.im","subject":"[PATCH 2/5] gitlab-ci: ignore failures to disable realtime monitoring","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-10-02T11:04:37Z","receivedAt":"2025-10-02T11:04:55Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"We have recently introduced a change to disable realtime monitoring for\nWindows job in GitLab CI. This change led (and still leads) to a quite\nsignificant speedup.\n\nBut there's a catch: seemingly, some of the runners we use already have\nrealtime monitoring disabled. On such a machine, trying to disable the\nfeature again leads to an error that causes the whole job to fail.\n\nSafeguard against such failures by explicitly ignoring them.\n\nSigned-off-by: Patrick Steinhardt <ps@pks.im>\n---\n .gitlab-ci.yml | 5 ++++-\n 1 file changed, 4 insertions(+), 1 deletion(-)\n\ndiff --git a/.gitlab-ci.yml b/.gitlab-ci.yml\nindex 552c033fb0..ed4dc9db94 100644\n--- a/.gitlab-ci.yml\n+++ b/.gitlab-ci.yml\n@@ -113,7 +113,10 @@ test:osx:\n     when: on_failure\n \n .windows_before_script: &windows_before_script\n-  - Set-MpPreference -DisableRealtimeMonitoring $true\n+  # Disabling realtime monitoring fails on some of the runners, but it\n+  # significantly speeds up test execution in the case where it works. We thus\n+  # try our luck, but ignore any failures.\n+  - Set-MpPreference -DisableRealtimeMonitoring $true; $true\n \n build:mingw64:\n   stage: build\n\n-- \n2.51.0.700.g236ee7b076.dirty\n\n"},{"id":"527784","messageId":"20251002-pks-gitlab-ci-windows-improvements-v1-3-6a8b6b45d728@pks.im","threadId":"64239","inReplyTo":"20251002-pks-gitlab-ci-windows-improvements-v1-0-6a8b6b45d728@pks.im","subject":"[PATCH 3/5] gitlab-ci: drop workaround for Python certificate store on Windows","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-10-02T11:04:38Z","receivedAt":"2025-10-02T11:04:56Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Windows, we have been running into some issues in the past where the\ncertificate store for Python is broken on the GitLab CI runners using\nWindows. The consequence was that we weren't able to establish any SSL\nconnections via Python, but we need that feature so that we can download\nthe Meson wraps. The workaround we employed was to import certificates\nfrom the cURL project into the certificate store via OpenSSL.\n\nThis is obviously an ugly workaround. But even more importantly, this\nworkaround fails every time Chocolatey updates its OpenSSL packages. The\nproblem here is that the old OpenSSL package installer will be removed\nimmediately once the newer version was published, But the Chocolatey\ncommunity repository may not yet have propagated the new version of this\npackage to all of its caches. The result is that for a couple hours (or\nsometimes even one or two days) we always fail to install OpenSSL until\nthe new version was propagated.\n\nLuckily though, it turns out that the workaround doesn't seem to be\nrequired anymore. Drop it to work around the intermittent failures and\nto clean up some now-unneeded legacy cruft.\n\nSigned-off-by: Patrick Steinhardt <ps@pks.im>\n---\n .gitlab-ci.yml | 10 +---------\n 1 file changed, 1 insertion(+), 9 deletions(-)\n\ndiff --git a/.gitlab-ci.yml b/.gitlab-ci.yml\nindex ed4dc9db94..b388154078 100644\n--- a/.gitlab-ci.yml\n+++ b/.gitlab-ci.yml\n@@ -157,17 +157,9 @@ test:mingw64:\n     - saas-windows-medium-amd64\n   before_script:\n     - *windows_before_script\n-    - choco install -y git meson ninja openssl\n+    - choco install -y git meson ninja\n     - Import-Module $env:ChocolateyInstall\\helpers\\chocolateyProfile.psm1\n     - refreshenv\n-    # The certificate store for Python on Windows is broken and fails to fetch\n-    # certificates, see https://bugs.python.org/issue36011. This seems to\n-    # mostly be an issue with how the GitLab image is set up as it is a\n-    # non-issue on GitHub Actions. Work around the issue by importing\n-    # cetrificates manually.\n-    - Invoke-WebRequest https://curl.haxx.se/ca/cacert.pem -OutFile cacert.pem\n-    - openssl pkcs12 -export -nokeys -in cacert.pem -out certs.pfx -passout \"pass:\"\n-    - Import-PfxCertificate -CertStoreLocation Cert:\\LocalMachine\\Root -FilePath certs.pfx\n \n build:msvc-meson:\n   extends: .msvc-meson\n\n-- \n2.51.0.700.g236ee7b076.dirty\n\n"},{"id":"527785","messageId":"20251002-pks-gitlab-ci-windows-improvements-v1-4-6a8b6b45d728@pks.im","threadId":"64239","inReplyTo":"20251002-pks-gitlab-ci-windows-improvements-v1-0-6a8b6b45d728@pks.im","subject":"[PATCH 4/5] gitlab-ci: upload Meson test logs as JUnit reports","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-10-02T11:04:39Z","receivedAt":"2025-10-02T11:04:59Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"When running tests, Meson knows to output both a test log as well as a\nJUnit test report that collates results. We don't currently upload these\nresults in our GitLab CI at all, which makes it hard to see which tests\nran, but also which of our tests may have failed.\n\nUpload these JUnit reports as artifacts to make this information more\naccessible. Note that we also do this for some jobs that don't use Meson\nand thus don't generate these reports in the first place. GitLab CI\nhandles missing reports gracefully though, so there is no reason to\nspecial-case those jobs that don't use Meson.\n\nSigned-off-by: Patrick Steinhardt <ps@pks.im>\n---\n .gitlab-ci.yml | 7 +++++++\n 1 file changed, 7 insertions(+)\n\ndiff --git a/.gitlab-ci.yml b/.gitlab-ci.yml\nindex b388154078..85401b34a5 100644\n--- a/.gitlab-ci.yml\n+++ b/.gitlab-ci.yml\n@@ -70,6 +70,8 @@ test:linux:\n   artifacts:\n     paths:\n       - t/failed-test-artifacts\n+    reports:\n+      junit: build/meson-logs/testlog.junit.xml\n     when: on_failure\n \n test:osx:\n@@ -110,6 +112,8 @@ test:osx:\n   artifacts:\n     paths:\n       - t/failed-test-artifacts\n+    reports:\n+      junit: build/meson-logs/testlog.junit.xml\n     when: on_failure\n \n .windows_before_script: &windows_before_script\n@@ -181,6 +185,9 @@ test:msvc-meson:\n   script:\n     - meson test -C build --no-rebuild --print-errorlogs --slice $Env:CI_NODE_INDEX/$Env:CI_NODE_TOTAL\n   parallel: 10\n+  artifacts:\n+    reports:\n+      junit: build/meson-logs/testlog.junit.xml\n \n test:fuzz-smoke-tests:\n   image: ubuntu:latest\n\n-- \n2.51.0.700.g236ee7b076.dirty\n\n"},{"id":"527786","messageId":"20251002-pks-gitlab-ci-windows-improvements-v1-5-6a8b6b45d728@pks.im","threadId":"64239","inReplyTo":"20251002-pks-gitlab-ci-windows-improvements-v1-0-6a8b6b45d728@pks.im","subject":"[PATCH 5/5] t8020: fix test failure due to indeterministic tag sorting","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-10-02T11:04:40Z","receivedAt":"2025-10-02T11:05:03Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"In e6c06e87a2 (last-modified: fix bug when some paths remain unhandled,\n2025-09-18), we have fixed a bug where under certain circumstances,\ngit-last-modified(1) would BUG because there's still some unhandled\npaths. The fix claims that the root cause here is criss-cross merges,\nand it adds a test case that seemingly exercises this.\n\nCuriously, this test case fails on some systems because the actual\noutput does not match our expectations:\n\n    diff --git a/expect b/actual\n    index 5271607..bdc620e 100644\n    --- a/expect\n    --- b/actual\n    @@ -1,3 +1,3 @@\n     km3 a\n    -k2 k\n    +km2 k\n     1 file\n    error: last command exited with $?=1\n    not ok 15 - last-modified with subdir and criss-cross merge\n\nThe output we see is git-name-rev(1) with `--annotate-stdin`. What it\ndoes is to take the output of git-last-modified(1), which contains\nobject IDs of the blamed commits, and convert those object IDs into the\nnames of the corresponding tags. Interestingly, we indeed have both \"k2\"\nand \"km2\" as tags, and even more interestingly both of these tags point\nto the same commit. So the output we get isn't _wrong_, as the tags are\nambiguous.\n\nBut why do both of these tags point to the same commit? \"km2\" really is\nsupposed to be a merge, but due to the way the test is constructed the\nmerge turns into a fast-forward merge. Which means that the resulting\ndoes not even contain a criss-cross merge in the first place! A quick\ntest though shows that the test indeed triggers the bug, so the initial\nanalysis that the behaviour is triggered by such merges must be wrong.\n\nAnd it is: seemingly, the issue isn't with criss-cross merges, but\nrather with a graph where different files in the same directory were\nmodified on both sides of a merge.\n\nRefactor the test so that we explicitly test for this specific situation\ninstead of mentioning the \"criss-cross merge\" red herring. As the test\nis very specific to the actual layout of the repository we also adapt it\nto use its own standalone repository.\n\nNote that this requires us to drop the `test_when_finished` call in\n`check_last_modified` because it's not supported to execute that\nfunction in a subshell.\n\nThis refactoring also fixes the original tag ambiguity that caused us to\nfail on some platforms.\n\nSigned-off-by: Patrick Steinhardt <ps@pks.im>\n---\n t/t8020-last-modified.sh | 34 +++++++++++++++++++---------------\n 1 file changed, 19 insertions(+), 15 deletions(-)\n\ndiff --git a/t/t8020-last-modified.sh b/t/t8020-last-modified.sh\nindex e13aad1439..61f00bc15c 100755\n--- a/t/t8020-last-modified.sh\n+++ b/t/t8020-last-modified.sh\n@@ -33,7 +33,6 @@ check_last_modified() {\n \tdone &&\n \n \tcat >expect &&\n-\ttest_when_finished \"rm -f tmp.*\" &&\n \tgit ${indir:+-C \"$indir\"} last-modified \"$@\" >tmp.1 &&\n \tgit name-rev --annotate-stdin --name-only --tags \\\n \t\t<tmp.1 >tmp.2 &&\n@@ -128,20 +127,25 @@ test_expect_success 'only last-modified files in the current tree' '\n \tEOF\n '\n \n-test_expect_success 'last-modified with subdir and criss-cross merge' '\n-\tgit checkout -b branch-k1 1 &&\n-\tmkdir -p a k &&\n-\ttest_commit k1 a/file2 &&\n-\tgit checkout -b branch-k2 &&\n-\ttest_commit k2 k/file2 &&\n-\tgit checkout branch-k1 &&\n-\ttest_merge km2 branch-k2 &&\n-\ttest_merge km3 3 &&\n-\tcheck_last_modified <<-\\EOF\n-\tkm3 a\n-\tk2 k\n-\t1 file\n-\tEOF\n+test_expect_success 'subdirectory modified via merge' '\n+\ttest_when_finished rm -rf repo &&\n+\tgit init repo &&\n+\t(\n+\t\tcd repo &&\n+\t\ttest_commit base &&\n+\t\tgit switch --create left &&\n+\t\tmkdir subdir &&\n+\t\ttest_commit left subdir/left &&\n+\t\tgit switch --create right base &&\n+\t\tmkdir subdir &&\n+\t\ttest_commit right subdir/right &&\n+\t\tgit switch - &&\n+\t\ttest_merge merge right &&\n+\t\tcheck_last_modified <<-\\EOF\n+\t\tmerge subdir\n+\t\tbase base.t\n+\t\tEOF\n+\t)\n '\n \n test_expect_success 'cross merge boundaries in blaming' '\n\n-- \n2.51.0.700.g236ee7b076.dirty\n\n"},{"id":"527787","messageId":"50aa008e-1cbf-4e77-8e51-6f2c32b6c12a@app.fastmail.com","threadId":"64239","inReplyTo":"20251002-pks-gitlab-ci-windows-improvements-v1-5-6a8b6b45d728@pks.im","subject":"Re: [PATCH 5/5] t8020: fix test failure due to indeterministic tag sorting","fromName":"Kristoffer Haugsbakk","fromEmail":"kristofferhaugsbakk@fastmail.com","sentAt":"2025-10-02T11:10:53Z","receivedAt":"2025-10-02T11:11:15Z","isPatch":true,"sender":{"key":"kristofferhaugsbakk@fastmail.com","avatar":null},"body":"On Thu, Oct 2, 2025, at 13:04, Patrick Steinhardt wrote:\n> [snip]\n>\n> But why do both of these tags point to the same commit? \"km2\" really is\n> supposed to be a merge, but due to the way the test is constructed the\n> merge turns into a fast-forward merge. Which means that the resulting\n> does not even contain a criss-cross merge in the first place! A quick\n\n“the resulting <noun>”\n\nBy the way these intro (paragraph) sentences like “But why do” and \n“And it is” really help connect the whole narrative in the message.  \nI’ve noticed the same thing on some other recent commits/patches.\n\n> test though shows that the test indeed triggers the bug, so the initial\n> analysis that the behaviour is triggered by such merges must be wrong.\n>\n>[snip]\n"},{"id":"527789","messageId":"aN5hA1inMQojbnXq@pks.im","threadId":"64239","inReplyTo":"50aa008e-1cbf-4e77-8e51-6f2c32b6c12a@app.fastmail.com","subject":"Re: [PATCH 5/5] t8020: fix test failure due to indeterministic tag sorting","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-10-02T11:24:51Z","receivedAt":"2025-10-02T11:24:58Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Thu, Oct 02, 2025 at 01:10:53PM +0200, Kristoffer Haugsbakk wrote:\n> On Thu, Oct 2, 2025, at 13:04, Patrick Steinhardt wrote:\n> > [snip]\n> >\n> > But why do both of these tags point to the same commit? \"km2\" really is\n> > supposed to be a merge, but due to the way the test is constructed the\n> > merge turns into a fast-forward merge. Which means that the resulting\n> > does not even contain a criss-cross merge in the first place! A quick\n> \n> “the resulting <noun>”\n\nAh, right. What's missing here is \"commit graph\". Fixed locally, will\nsend out with the next iteration.\n\nThanks!\n\nPatrick\n"},{"id":"527966","messageId":"875xcsbae7.fsf@iotcl.com","threadId":"64239","inReplyTo":"20251002-pks-gitlab-ci-windows-improvements-v1-3-6a8b6b45d728@pks.im","subject":"Re: [PATCH 3/5] gitlab-ci: drop workaround for Python certificate store on Windows","fromName":"Toon Claes","fromEmail":"toon@iotcl.com","sentAt":"2025-10-06T10:19:12Z","receivedAt":"2025-10-06T10:19:30Z","isPatch":true,"sender":{"key":"toon@iotcl.com","avatar":"https://avatars.githubusercontent.com/u/121621?v=4"},"body":"Patrick Steinhardt <ps@pks.im> writes:\n\n> On Windows, we have been running into some issues in the past where the\n> certificate store for Python is broken on the GitLab CI runners using\n> Windows. The consequence was that we weren't able to establish any SSL\n> connections via Python, but we need that feature so that we can download\n> the Meson wraps. The workaround we employed was to import certificates\n> from the cURL project into the certificate store via OpenSSL.\n>\n> This is obviously an ugly workaround. But even more importantly, this\n> workaround fails every time Chocolatey updates its OpenSSL packages. The\n> problem here is that the old OpenSSL package installer will be removed\n> immediately once the newer version was published, But the Chocolatey\n> community repository may not yet have propagated the new version of this\n> package to all of its caches. The result is that for a couple hours (or\n> sometimes even one or two days) we always fail to install OpenSSL until\n> the new version was propagated.\n>\n> Luckily though, it turns out that the workaround doesn't seem to be\n> required anymore. Drop it to work around the intermittent failures and\n> to clean up some now-unneeded legacy cruft.\n\nI assume this is a result of this change:\nhttps://gitlab.com/gitlab-org/ci-cd/shared-runners/images/gcp/windows-containers/-/merge_requests/72\n\nMakes sense to clean this up.\n\n-- \nCheers,\nToon\n"},{"id":"527967","messageId":"874iscbabu.fsf@iotcl.com","threadId":"64239","inReplyTo":"20251002-pks-gitlab-ci-windows-improvements-v1-5-6a8b6b45d728@pks.im","subject":"Re: [PATCH 5/5] t8020: fix test failure due to indeterministic tag sorting","fromName":"Toon Claes","fromEmail":"toon@iotcl.com","sentAt":"2025-10-06T10:20:37Z","receivedAt":"2025-10-06T10:21:00Z","isPatch":true,"sender":{"key":"toon@iotcl.com","avatar":"https://avatars.githubusercontent.com/u/121621?v=4"},"body":"Patrick Steinhardt <ps@pks.im> writes:\n\n> In e6c06e87a2 (last-modified: fix bug when some paths remain unhandled,\n> 2025-09-18), we have fixed a bug where under certain circumstances,\n> git-last-modified(1) would BUG because there's still some unhandled\n> paths. The fix claims that the root cause here is criss-cross merges,\n> and it adds a test case that seemingly exercises this.\n>\n> Curiously, this test case fails on some systems because the actual\n> output does not match our expectations:\n>\n>     diff --git a/expect b/actual\n>     index 5271607..bdc620e 100644\n>     --- a/expect\n>     --- b/actual\n>     @@ -1,3 +1,3 @@\n>      km3 a\n>     -k2 k\n>     +km2 k\n>      1 file\n>     error: last command exited with $?=1\n>     not ok 15 - last-modified with subdir and criss-cross merge\n>\n> The output we see is git-name-rev(1) with `--annotate-stdin`. What it\n> does is to take the output of git-last-modified(1), which contains\n> object IDs of the blamed commits, and convert those object IDs into the\n> names of the corresponding tags. Interestingly, we indeed have both \"k2\"\n> and \"km2\" as tags, and even more interestingly both of these tags point\n> to the same commit. So the output we get isn't _wrong_, as the tags are\n> ambiguous.\n\nAhha, I see...\n\n> But why do both of these tags point to the same commit? \"km2\" really is\n> supposed to be a merge, but due to the way the test is constructed the\n> merge turns into a fast-forward merge.\n\nOhw :o\n\n> Which means that the resulting\n> does not even contain a criss-cross merge in the first place! A quick\n> test though shows that the test indeed triggers the bug, so the initial\n> analysis that the behaviour is triggered by such merges must be wrong.\n\nI've tried various things, this felt like the simplest case to\nreproduce. Apparantly not realizing it was wrong.\n\n> And it is: seemingly, the issue isn't with criss-cross merges, but\n> rather with a graph where different files in the same directory were\n> modified on both sides of a merge.\n\nWell yes, it felt like it was something like this. But like said, it\n_seemed_ I needed a criss-cross merge.\n\n> Refactor the test so that we explicitly test for this specific situation\n> instead of mentioning the \"criss-cross merge\" red herring.\n\nWell, thanks for this cleanup!\n\n> As the test\n> is very specific to the actual layout of the repository we also adapt it\n> to use its own standalone repository.\n\nI should have done that in the first place. Trying to shoe horn this\ntest in the existing repo might have guided me to take incorrect\nconclusions.\n> Note that this requires us to drop the `test_when_finished` call in\n> `check_last_modified` because it's not supported to execute that\n> function in a subshell.\n\nThis is not an issue because these files are always overwritten before\ncomparing, so this the `rm` wasn't strictly needed.\n\n> This refactoring also fixes the original tag ambiguity that caused us to\n> fail on some platforms.\n\nAwesome! \n\n> Signed-off-by: Patrick Steinhardt <ps@pks.im>\n> ---\n>  t/t8020-last-modified.sh | 34 +++++++++++++++++++---------------\n>  1 file changed, 19 insertions(+), 15 deletions(-)\n>\n> diff --git a/t/t8020-last-modified.sh b/t/t8020-last-modified.sh\n> index e13aad1439..61f00bc15c 100755\n> --- a/t/t8020-last-modified.sh\n> +++ b/t/t8020-last-modified.sh\n> @@ -33,7 +33,6 @@ check_last_modified() {\n>  \tdone &&\n>  \n>  \tcat >expect &&\n> -\ttest_when_finished \"rm -f tmp.*\" &&\n>  \tgit ${indir:+-C \"$indir\"} last-modified \"$@\" >tmp.1 &&\n>  \tgit name-rev --annotate-stdin --name-only --tags \\\n>  \t\t<tmp.1 >tmp.2 &&\n> @@ -128,20 +127,25 @@ test_expect_success 'only last-modified files in the current tree' '\n>  \tEOF\n>  '\n>  \n> -test_expect_success 'last-modified with subdir and criss-cross merge' '\n> -\tgit checkout -b branch-k1 1 &&\n> -\tmkdir -p a k &&\n> -\ttest_commit k1 a/file2 &&\n> -\tgit checkout -b branch-k2 &&\n> -\ttest_commit k2 k/file2 &&\n> -\tgit checkout branch-k1 &&\n> -\ttest_merge km2 branch-k2 &&\n> -\ttest_merge km3 3 &&\n> -\tcheck_last_modified <<-\\EOF\n> -\tkm3 a\n> -\tk2 k\n> -\t1 file\n> -\tEOF\n> +test_expect_success 'subdirectory modified via merge' '\n> +\ttest_when_finished rm -rf repo &&\n> +\tgit init repo &&\n> +\t(\n> +\t\tcd repo &&\n> +\t\ttest_commit base &&\n> +\t\tgit switch --create left &&\n> +\t\tmkdir subdir &&\n> +\t\ttest_commit left subdir/left &&\n> +\t\tgit switch --create right base &&\n> +\t\tmkdir subdir &&\n> +\t\ttest_commit right subdir/right &&\n> +\t\tgit switch - &&\n> +\t\ttest_merge merge right &&\n> +\t\tcheck_last_modified <<-\\EOF\n> +\t\tmerge subdir\n> +\t\tbase base.t\n> +\t\tEOF\n> +\t)\n>  '\n\nLooks good to me.\n\n-- \nCheers,\nToon\n"}]}