aboutsummaryrefslogtreecommitdiffstats
path: root/t/t6011-rev-list-with-bad-commit.sh (follow)
AgeCommit message (Collapse)AuthorFilesLines
2025-05-07t6011: fix misconversion from perl to sedJunio C Hamano1-0/+1
No, this is not about a quiz on regexp compatibility between Perl and sed. Back when cdbdc6bf (t: refactor tests depending on Perl substitution operator, 2025-04-03) rewrote many uses of perl with sed, the general pattern of the original scripts were chmod +w some_read_only_file && perl -p -e "regexp to munge" some_read_only_file >some_tmp && mv some_tmp some_read_only_file persumably because the author knew that replacing some_read_only_file with "mv" at the last step would not work without "mv -f" in some environments (GNU seems to succeed without giving any prompt when not running interactively, which is what happens when running t/ scripts). Replacing perl with sed would be fine as long as sed with updated regexp does the equivalent munging. But one place used to use a different construct in the original: perl -i.bak -p -e "regexp to munge" some_read_only_file With _no_ temporary file or "mv", "perl -i" allows you to replace a read-only file in place. When we replaced the use of "perl" with "sed" in the said commit, however, because "sed -i" is not portable, we rewrote that in-place replacement to sed "regexp to munge" some_read_only_file >some_tmp && mv some_tmp some_read_only_file Again, unfortunately that does not work in some environment, without "mv -f". We could run "mv -f" here, but we would then need to remove "chmod +w" and have them use "mv -f" instead at all places that were touched cdbdc6bf (t: refactor tests depending on Perl substitution operator, 2025-04-03) to be consistent (and more concise). For now, let's make it consistent in the other direction by mimick the other places that made the target read-write before moving. Speaking of portability, the outcome of using "sed" on non-text files is unspecified, so the entire exercise of cdbdc6bf may have needed to be reverted if people still used ancient version of "standard compliant" sed that barfs on non-text files, but these days we may be able to get away with "BSDs and GNU seem OK with it" ;-) But one fix at a time. Reported-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-07t: refactor tests depending on Perl substitution operatorPatrick Steinhardt1-11/+9
We have a bunch of tests that use Perl to perform substitution via the "s/" operator. These usecases can be trivially replaced with sed(1) and tr(1). Refactor the tests accordingly so that we can drop a couple of PERL_TEST_HELPERS prerequisites. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-07t: introduce PERL_TEST_HELPERS prerequisitePatrick Steinhardt1-0/+6
In the early days of Git, Perl was used quite prominently throughout the project. This has changed significantly as almost all of the executables we ship nowadays have eventually been rewritten in C. Only a handful of subsystems remain that require Perl: - gitweb, a read-only web interface. - A couple of scripts that allow importing repositories from GNU Arch, CVS and Subversion. - git-send-email(1), which can be used to send mails. - git-request-pull(1), which is used to request somebody to pull from a URL by sending an email. - git-filter-branch(1), which uses Perl with the `--state-branch` option. This command is typically recommended against nowadays in favor of git-filter-repo(1). - Our Perl bindings for Git. - The netrc Git credential helper. None of these subsystems can really be considered to be part of the "core" of Git, and an installation without them is fully functional. It is more likely than not that an end user wouldn't even notice that any features are missing if those tools weren't installed. But while Perl nowadays very much is an optional dependency of Git, there is a significant limitation when Perl isn't available: developers cannot run our test suite. Preceding commits have started to lift this restriction by removing the strict dependency on Perl in many central parts of the test library. But there are still many tests that rely on small Perl helpers to do various different things. Introduce a new PERL_TEST_HELPERS prerequisite that guards all tests that require Perl. This prerequisite is explicitly different than the preexisting PERL prerequisite: - PERL records whether or not features depending on the Perl interpreter are built. - PERL_TEST_HELPERS records whether or not a Perl interpreter is available for our tests. By having these two separate prerequisites we can thus distinguish between tests that inherently depend on Perl because the underlying feature does, and those tests that depend on Perl because the test itself is using Perl. Adapt all tests to set the PERL_TEST_HELPERS prerequisite as needed. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-11-21t: remove TEST_PASSES_SANITIZE_LEAK annotationsPatrick Steinhardt1-1/+0
Now that the default value for TEST_PASSES_SANITIZE_LEAK is `true` there is no longer a need to have that variable declared in all of our tests. Drop it. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-02-06repack: fix leaks on error with "goto cleanup"Ævar Arnfjörð Bjarmason1-0/+1
In cmd_repack() when we hit an error, replace "return ret" with "goto cleanup" to ensure we free the necessary data structures. Helped-by: Elijah Newren <newren@gmail.com> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-13commit-graph: turn on commit-graph by defaultDerrick Stolee1-1/+1
The commit-graph feature has seen a lot of activity in the past year or so since it was introduced. The feature is a critical performance enhancement for medium- to large-sized repos, and does not significantly hurt small repos. Change the defaults for core.commitGraph and gc.writeCommitGraph to true so users benefit from this feature by default. There are several places in the test suite where the environment variable GIT_TEST_COMMIT_GRAPH is disabled to avoid reading a commit-graph, if it exists. The config option overrides the environment, so swap these. Some GIT_TEST_COMMIT_GRAPH assignments remain, and those are to avoid writing a commit-graph when a new commit is created. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-29commit-graph: define GIT_TEST_COMMIT_GRAPHDerrick Stolee1-4/+3
The commit-graph feature is tested in isolation by t5318-commit-graph.sh and t6600-test-reach.sh, but there are many more interesting scenarios involving commit walks. Many of these scenarios are covered by the existing test suite, but we need to maintain coverage when the optional commit-graph structure is not present. To allow running the full test suite with the commit-graph present, add a new test environment variable, GIT_TEST_COMMIT_GRAPH. Similar to GIT_TEST_SPLIT_INDEX, this variable makes every Git command try to load the commit-graph when parsing commits, and writes the commit-graph file after every 'git commit' command. There are a few tests that rely on commits not existing in pack-files to trigger important events, so manually set GIT_TEST_COMMIT_GRAPH to false for the necessary commands. There is one test in t6024-recursive-merge.sh that relies on the merge-base algorithm picking one of two ambiguous merge-bases, and the commit-graph feature changes which merge-base is picked. Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-29t: use perl instead of "$PERL_PATH" where applicableJeff King1-1/+1
As of the last commit, we can use "perl" instead of "$PERL_PATH" when running tests, as the former is now a function which uses the latter. As the shorter "perl" is easier on the eyes, let's switch to using it everywhere. This is not quite a mechanical s/$PERL_PATH/perl/ replacement, though. There are some places where we invoke perl from a script we generate on the fly, and those scripts do not have access to our internal shell functions. The result can be double-checked by running: ln -s /bin/false bin-wrappers/perl make test which continues to pass even after this patch. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-24tests: enclose $PERL_PATH in double quotesJunio C Hamano1-1/+1
Otherwise it will be split at a space after "Program" when it is set to "\\Program Files\perl" or something silly like that. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-12t: Replace 'perl' by $PERL_PATHVincent van Ravesteijn1-1/+1
GIT-BUILD-OPTIONS defines PERL_PATH to be used in the test suite. Only a few tests already actually use this variable when perl is needed. The other test just call 'perl' and it might happen that the wrong perl interpreter is used. This becomes problematic on Windows, when the perl interpreter that is compiled and installed on the Windows system is used, because this perl interpreter might introduce some unexpected LF->CRLF conversions. This patch makes sure that $PERL_PATH is used everywhere in the test suite and that the correct perl interpreter is used. Signed-off-by: Vincent van Ravesteijn <vfr@lyx.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-14restore legacy behavior for read_sha1_file()Nicolas Pitre1-0/+60
Since commit 8eca0b47ff1598a6d163df9358c0e0c9bd92d4c8, it is possible for read_sha1_file() to return NULL even with existing objects when they are corrupted. Previously a corrupted object would have terminated the program immediately, effectively making read_sha1_file() return NULL only when specified object is not found. Let's restore this behavior for all users of read_sha1_file() and provide a separate function with the ability to not terminate when bad objects are encountered. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>