git/t, branch v2.50.0

Merge branch 'mm/test-in-absolute-home'

2025-06-09T14:15:51Z

Tests that compare $HOME and $(pwd), which should be the same directory unless the tests chdir's around, would fail when the user enters the test directory via symbolic links, which has been corrected. * mm/test-in-absolute-home: t: run tests from a normalized working directory

Merge branch 'js/t5410-tee-hang-workaround'

2025-06-05T18:56:29Z

* js/t5410-tee-hang-workaround: t5410: avoid hangs in CI runs in the win+Meson test jobs

t5410: avoid hangs in CI runs in the win+Meson test jobs

2025-06-05T16:45:42Z

In the GitHub workflow used in Git's CI builds, the `vs test` jobs use a subset of a specific revision of Git for Windows' SDK to run Git's test suite. This revision is validated by another CI workflow to ensure that said revision _can_ run Git's test suite successfully, skipping buggy updates in Git for Windows' SDK. The `win+Meson test` jobs do things differently, quite differently. They use the Bash of the Git for Windows version that is installed on the runners to run Git's test suite. This difference has consequences. When 68cb0b5253a0 (builtin/receive-pack: add option to skip connectivity check, 2025-05-20) introduced a test case that uses `tee | git receive-pack` as `--receive-pack` parameter (imitating an existing pattern in the same test script), it hit just the sweet spot to trigger a bug in the MSYS2 runtime shipped in Git for Windows v2.49.0. This version is the one currently installed on GitHub's runners. The problem is that the `git receive-pack` process finishes while the `tee` process does not need to write anything anymore and therefore does not receive an EOF. Instead, it should receive a SIGPIPE, but the bug in the MSYS2 runtime prevents that from working as intended. As a consequence, the `tee` process waits for more input from the `git.exe send-pack` process but none is coming, and the test script patiently waits until the 6h timeout hits. Only every once in a while, the `git receive-pack` process manages to send an EOF to the `tee` process and no hang occurs. Therefore, the problem can be worked around by cancelling the clearly-hanging job after twenty or so minutes and re-running it, repeating the process about half a dozen times, until the hang was successfully avoided. This bug in the MSYS2 runtime has been fixed in the meantime, which is the reason why the same test case causes no problems in the `win test` and the `vs test` jobs. This will continue to be the case until the Git for Windows version on the GitHub runners is upgraded to a version that distributes a newer MSYS2 runtime version. However, as of time of writing, this _is_ the latest Git for Windows version, and will be for another 1.5 weeks, until Git v2.50.0 is scheduled to appear (and shortly thereafter Git for Windows v2.50.0). Traditionally it takes a while before the runners pick up the new version. We could just wait it out, six hours at a time. Here, I opt for an alternative: Detect the buggy MSYS2 runtime and simply skip the test case. It's not like the `receive-pack` test cases are specific to Windows, and even then, to my chagrin the CI runs in git-for-windows/git spend around ten hours of compute time each and every time to run the entire test suite on all the platforms, even the tests that cover cross-platform code, and for Windows alone we do that three times: with GCC, with MSVC, and with MSVC via Meson. Therefore, I deem it more than acceptable to skip this test case in one of those matrices. For good luck, also the preceding test case is skipped in that scenario, as it uses the same `--receive-pack=tee | git receive-pack` pattern, even though I never observed that test case to hang in practice. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

Merge branch 'sj/ref-contents-check-fix'

2025-06-03T15:55:23Z

"git verify-refs" (and hence "git fsck --reference") started erroring out in a repository in which secondary worktrees were prepared with Git 2.43 or lower. * sj/ref-contents-check-fix: fsck: ignore missing "refs" directory for linked worktrees

fsck: ignore missing "refs" directory for linked worktrees

2025-06-02T18:20:19Z

"git refs verify" doesn't work if there are worktrees created on Git v2.43.0 or older versions. These versions don't automatically create the "refs" directory, causing the error: error: cannot open directory .git/worktrees//refs: No such file or directory Since 8f4c00de95 (builtin/worktree: create refdb via ref backend, 2024-01-08), we automatically create the "refs" directory for new worktrees. And in 7c78d819e6 (ref: support multiple worktrees check for refs, 2024-11-20), we assume that all linked worktrees have this directory and would wrongly report an error to the user, thus introducing compatibility issue. Check for ENOENT errno before reporting directory access errors for linked worktrees to maintain backward compatibility. Reported-by: Kristoffer Haugsbakk Signed-off-by: shejialuo Signed-off-by: Junio C Hamano

Merge branch 'jc/signed-fast-export-is-experimental'

2025-06-02T16:25:34Z

Mark a new feature added during this cycle as experimental and fix its default so that existing users of the fast-export command is not broken. * jc/signed-fast-export-is-experimental: fast-export: --signed-commits is experimental

t: run tests from a normalized working directory

2025-05-30T21:55:03Z

Some tests make git perform actions that produce observable pathnames, and have expectations on those paths. Tests run with $HOME set to a $TRASH_DIRECTORY, and with their working directory the same $TRASH_DIRECTORY, although these paths are logically identical, they do not observe the same pathname canonicalization rules and thus might not be represented by strings that compare equal. In particular, no pathname normalization is applied to $TRASH_DIRECTORY or $HOME, while tests change their working directory with `cd -P`, which normalizes the working directory's path by fully resolving symbolic links. t7900's macOS maintenance tests (which are not limited to running on macOS) have an expectation on a path that `git maintenance` forms by using abspath.c strbuf_realpath() to resolve a canonical absolute path based on $HOME. When t7900 runs from a working directory that contains symbolic links in its pathname, $HOME will also contain symbolic links, which `git maintenance` resolves but the test's expectation does not, causing a test failure. Align $TRASH_DIRECTORY and $HOME with the normalized path as used for the working directory by resetting them to match the working directory after it's established by `cd -P`. With all paths in agreement and symbolic links resolved, pathname expectations can be set and met based on string comparison without regard to external environmental factors such as the presence of symbolic links in a path. Suggested-by: Junio C Hamano Signed-off-by: Mark Mentovai Signed-off-by: Junio C Hamano

Merge branch 'mm/apply-reverse-mode-of-deleted-path'

2025-05-30T18:59:17Z

"git apply --index/--cached" when applying a deletion patch in reverse failed to give the mode bits of the path "removed" by the patch to the file it creates, which has been corrected. * mm/apply-reverse-mode-of-deleted-path: apply: set file mode when --reverse creates a deleted file t4129: test that git apply warns for unexpected mode changes

fast-export: --signed-commits is experimental

2025-05-28T17:30:47Z

As the design of signature handling is still being discussed, it is likely that the data stream produced by the code in Git 2.50 would have to be changed in such a way that is not backward compatible. Mark the feature as experimental and discourge its use for now. Also flip the default on the generation side to "strip"; users of existing versions would not have passed --signed-commits=strip and will be broken by this change if the default is made to abort, and will be encouraged by the error message to produce data stream with future breakage guarantees by passing --signed-commits option. As we tone down the default behaviour, we no longer need the FAST_EXPORT_SIGNED_COMMITS_NOABORT environment variable, which was not discoverable enough. Signed-off-by: Junio C Hamano

Merge branch 'jt/receive-pack-skip-connectivity-check'

2025-05-28T14:59:56Z

"git receive-pack" optionally learns not to care about connectivity check, which can be useful when the repository arranges to ensure connectivity by some other means. * jt/receive-pack-skip-connectivity-check: builtin/receive-pack: add option to skip connectivity check t5410: test receive-pack connectivity check