git/t/t9700, branch next

t9700/test.pl: fix path type expectation on cygwin

2026-01-16T21:59:57Z

Commit 4ec7ac101b ("t9700: accommodate for Windows paths", 2025-12-17) changed the type of the absolute path to the git directory from unix to win32 for both GfW and cygwin. This fixed the test for GfW but causes new failures on cygwin, since the test expectation is that it uses unix paths on cygwin. In order to not break cygwin, disable the new code by removing the "or $^O eq 'cygwin'" sub-expression from the conditional part of the fix. Signed-off-by: Ramsay Jones Signed-off-by: Junio C Hamano

t9700: accommodate for Windows paths

2025-12-17T23:18:12Z

Ever since fe53bbc9beb (Git.pm: Always set Repository to absolute path if autodetecting, 2009-05-07), the t9700 test _must_ fail on Windows because of that age-old Unix paths vs Windows paths problem. The underlying root cause is that Git cannot run with a regular Win32 variant of Perl, the assumption that every path is a Unix path is just too strong in Git's Perl code. As a consequence, Git for Windows is basically stuck with using the MSYS2 variant of Perl which uses a POSIX emulation layer (which is a friendly fork of Cygwin) _and_ a best-effort Unix <-> Windows paths conversion whenever crossing the boundary between MSYS2 and regular Win32 processes. It is best effort only, though, using heuristics to automagically convert correctly in most cases, but not in all cases. In the context of this here patch, this means that asking `git.exe` for the absolute path of the `.git/` directory will return a Win32 path because `git.exe` is a regular Win32 executable that has no idea about Unix-ish paths. But above-mentioned commit introduced a test that wants to verify that this path is identical to the one that the Git Perl module reports (which refuses to use Win32 paths and uses Unix-ish paths instead). Obviously, this must fail because no heuristics can kick in at that layer. This test failure has not even been caught when Git introduced Windows support in its CI definition in 2e90484eb4a (ci: add a Windows job to the Azure Pipelines definition, 2019-01-29), as all tests relying on Perl had to be disabled even from the start (because the CI runs would otherwise have resulted in prohibitively long runtimes, not because Windows is super slow per se, but because Git's test suite keeps insisting on using technology that requires a POSIX emulation layer, which _is_ super slow on Windows). To work around this failure, let's use the `cygpath` utility to convert the absolute `gitdir` path into the form that the Perl code expects. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

Require Perl 5.26.0

2024-10-23T20:16:36Z

Our platform support policy states that we require "versions of dependencies which are generally accepted as stable and supportable, e.g., in line with the version used by other long-term-support distributions". Of Debian, Ubuntu, RHEL, and SLES, the four most common distributions that provide LTS versions, the version with mainstream long-term security support with the oldest Perl is 5.26.0 in SLES 15.6. This is a major upgrade, since Perl 5.8.1, according to the Perl documentation, was released in September of 2003. It brings a lot of new features that we can choose to use, such as s///r to return the modified string, the postderef functionality, and subroutine signatures, although the latter was still considered experimental until 5.36. This change was made with the following one-liner, which intentionally excludes modifying the vendored modules we include to avoid conflicts: git grep -l 'use 5.008001' | grep -v 'LoadCPAN/' | xargs perl -pi -e 's/use 5.008001/require v5.26/' Use require instead of use to avoid changing the behavior as the latter enables features and the former does not. Signed-off-by: brian m. carlson Signed-off-by: Taylor Blau

Merge branch 'jk/git-pm-bare-repo-fix'

2024-09-20T18:16:33Z

In Git 2.39, Git.pm stopped working in a bare repository, which has been corrected. * jk/git-pm-bare-repo-fix: Git.pm: use "rev-parse --absolute-git-dir" rather than perl code Git.pm: fix bare repository search with Directory option

Git.pm: fix bare repository search with Directory option

2024-09-13T17:42:19Z

When opening a bare repository like: Git->repository(Directory => '/path/to/bare.git'); we will incorrectly point the repository object at the _current_ directory, not the one specified by the option. The bug was introduced by 20da61f25f (Git.pm: trust rev-parse to find bare repositories, 2022-10-22). Before then, we'd ask "rev-parse --git-dir" if it was a Git repo, and if it returned anything, we'd correctly convert that result to an absolute path using File::Spec and Cwd::abs_path(). If it didn't, we'd guess it might be a bare repository and find it ourselves, which was wrong (rev-parse should find even a bare repo, and our search circumvented some of its rules). That commit dropped most of the custom bare-repo search code in favor of using "rev-parse --is-bare-repository" and trusting the "--git-dir" it returned. But it mistakenly left some of the bare-repo code path in place, which was now broken. That code calls Cwd::abs_path($dir); prior to 20da61f25f $dir contained the "Directory" option the user passed in. But afterwards, it contains the output of "rev-parse --git-dir". And since our tentative rev-parse command is invoked after changing directory, it will always be the relative path "."! So we'll end up with the absolute path of the process's current directory, not the Directory option the caller asked for. So the non-bare case is correct, but the bare one is broken. Our tests only check the non-bare one, so we didn't notice. We can fix this by running the same absolute-path fixup code for both sides. Helped-by: Rodrigo Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

perl: bump the required Perl version to 5.8.1 from 5.8.0

2023-11-16T22:26:32Z

The following commit will make use of a Getopt::Long feature which is only present in Perl >= 5.8.1. Document that as the minimum version we support. Many of our Perl scripts will continue to run with 5.8.0 but this change allows us to adjust them as needed without breaking any promises to our users. The Perl requirement was last changed in d48b284183 (perl: bump the required Perl version to 5.8 from 5.6.[21], 2010-09-24). At that time, 5.8.0 was 8 years old. It is now over 21 years old. Signed-off-by: Todd Zullinger Signed-off-by: Junio C Hamano

Git.pm: trust rev-parse to find bare repositories

2022-10-22T23:39:48Z

When initializing a repository object, we run "git rev-parse --git-dir" to let the C version of Git find the correct directory. But curiously, if this fails we don't automatically say "not a git repository". Instead, we do our own pure-perl check to see if we're in a bare repository. This makes little sense, as rev-parse will report both bare and non-bare directories. This logic comes from d5c7721d58 (Git.pm: Add support for subdirectories inside of working copies, 2006-06-24), but I don't see any reason given why we can't just rely on rev-parse. Worse, because we treat any non-error response from rev-parse as a non-bare repository, we'll erroneously set the object's WorkingCopy, even in a bare repository. But it gets worse. Since 8959555cee (setup_git_directory(): add an owner check for the top-level directory, 2022-03-02), it's actively wrong (and dangerous). The perl code doesn't implement the same ownership checks. And worse, after "finding" the bare repository, it sets GIT_DIR in the environment, which tells any subsequent Git commands that we've confirmed the directory is OK, and to trust us. I.e., it re-opens the vulnerability plugged by 8959555cee when using Git.pm's repository discovery code. We can fix this by just relying on rev-parse to tell us when we're not in a repository, which fixes the vulnerability. Furthermore, we'll ask its --is-bare-repository function to tell us if we're bare or not, and rely on that. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'bc/sha-256-part-3'

2020-08-12T01:04:11Z

The final leg of SHA-256 transition. * bc/sha-256-part-3: (39 commits) t: remove test_oid_init in tests docs: add documentation for extensions.objectFormat ci: run tests with SHA-256 t: make SHA1 prerequisite depend on default hash t: allow testing different hash algorithms via environment t: add test_oid option to select hash algorithm repository: enable SHA-256 support by default setup: add support for reading extensions.objectformat bundle: add new version for use with SHA-256 builtin/verify-pack: implement an --object-format option http-fetch: set up git directory before parsing pack hashes t0410: mark test with SHA1 prerequisite t5308: make test work with SHA-256 t9700: make hash size independent t9500: ensure that algorithm info is preserved in config t9350: make hash size independent t9301: make hash size independent t9300: use $ZERO_OID instead of hard-coded object ID t9300: abstract away SHA-1-specific constants t8011: make hash size independent ...

t9700: make hash size independent

2020-07-30T16:16:48Z

The Perl test script for t9700 was matching on exactly 40 hex characters. With SHA-256, we'll have 64 hex-character object IDs. Create a variable with a regex which matches exactly 40 or 64 hex characters and use that to match the output. Note that both of the uses of this can be anchored, which makes the code simpler, so do that as well. Signed-off-by: brian m. carlson Reviewed-by: Eric Sunshine Signed-off-by: Junio C Hamano

t9700: loosen ident timezone regex

2020-07-10T18:56:01Z

A few of the perl tests in t9700 ask for the author and committer ident, and then make sure we get something sensible. For the timestamp portion, we just match [0-9]+, because the actual value will depend on when the test is run. However, we do require that the timezone be "+0000". This works reliably because we set $TZ in test-lib.sh. But in preparation for changing the default timezone, let's be a bit more flexible. We don't actually care about the exact value here, just that we were able to get a sensible output from the perl module's access methods. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano