path: root/t/
AgeCommit message (Collapse)Author
2021-08-30Merge branch 'jk/apply-binary-hunk-parsing-fix'Junio C Hamano
"git apply" miscounted the bytes and failed to read to the end of binary hunks. * jk/apply-binary-hunk-parsing-fix: apply: keep buffer/size pair in sync when parsing binary hunks
2021-08-10apply: keep buffer/size pair in sync when parsing binary hunksJeff King
We parse through binary hunks by looping through the buffer with code like: llen = linelen(buffer, size); something with the line... buffer += llen; size -= llen; However, before we enter the loop, there is one call that increments "buffer" but forgets to decrement "size". As a result, our "size" is off by the length of that line, and subsequent calls to linelen() may look past the end of the buffer for a newline. The fix is easy: we just need to decrement size as we do elsewhere. This bug goes all the way back to 0660626caf (binary diff: further updates., 2006-05-05). Presumably nobody noticed because it only triggers if the patch is corrupted, and even then we are often "saved" by luck. We use a strbuf to store the incoming patch, so we overallocate there, plus we add a 16-byte run of NULs as slop for memory comparisons. So if this happened accidentally, the common case is that we'd just read a few uninitialized bytes from the end of the strbuf before producing the expected "this patch is corrupted" error complaint. However, it is possible to carefully construct a case which reads off the end of the buffer. The included test does so. It will pass both before and after this patch when run normally, but using a tool like ASan shows that we get an out-of-bounds read before this patch, but not after. Reported-by: Xingman Chen <> Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2020-11-19t4*: adjust the references to the default branch name "main"Johannes Schindelin
Carefully excluding t4013 and t4015, which see independent development elsewhere at the time of writing, we use `main` as the default branch name in t4*. This trick was performed via $ (cd t && sed -i -e 's/master/main/g' -e 's/MASTER/MAIN/g' \ -e 's/Master/Main/g' -- t4*.sh t4211/*.export && git checkout HEAD -- t4013\*) This allows us to define `GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main` for those tests. Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2020-11-19tests: mark tests relying on the current default for `init.defaultBranch`Johannes Schindelin
In addition to the manual adjustment to let the `linux-gcc` CI job run the test suite with `master` and then with `main`, this patch makes sure that GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME is set in all test scripts that currently rely on the initial branch name being `master by default. To determine which test scripts to mark up, the first step was to force-set the default branch name to `master` in - all test scripts that contain the keyword `master`, - t4211, which expects `t/t4211/history.export` with a hard-coded ref to initialize the default branch, - t5560 because it sources `t/t556x_common` which uses `master`, - t8002 and t8012 because both source `t/` which also uses `master`) This trick was performed by this command: $ sed -i '/^ *\. \.\/\(test-lib\|lib-\(bash\|cvs\|git-svn\)\|gitweb-lib\)\.sh$/i\ GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\ export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\ ' $(git grep -l master t/t[0-9]*.sh) \ t/t4211*.sh t/t5560*.sh t/t8002*.sh t/t8012*.sh After that, careful, manual inspection revealed that some of the test scripts containing the needle `master` do not actually rely on a specific default branch name: either they mention `master` only in a comment, or they initialize that branch specificially, or they do not actually refer to the current default branch. Therefore, the aforementioned modification was undone in those test scripts thusly: $ git checkout HEAD -- \ t/ t/ \ t/ \ t/ t/ \ t/ t/ \ t/ \ t/ \ t/ t/ \ t/ t/ \ t/ \ t/ t/ \ t/ t/ \ t/ t/ \ t/ t/ \ t/ \ t/ \ t/ t/ \ t/ \ t/ t/ \ t/ We excluded one set of test scripts in these commands, though: the range of `git p4` tests. The reason? `git p4` stores the (foreign) remote branch in the branch called `p4/master`, which is obviously not the default branch. Manual analysis revealed that only five of these tests actually require a specific default branch name to pass; They were modified thusly: $ sed -i '/^ *\. \.\/lib-git-p4\.sh$/i\ GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\ export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\ ' t/t980[0167]*.sh t/t9811*.sh Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2013-10-29t: use perl instead of "$PERL_PATH" where applicableJeff King
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 <> Signed-off-by: Junio C Hamano <>
2012-09-07Merge branch 'jc/apply-binary-p0'Junio C Hamano
"git apply -p0" did not parse pathnames on "diff --git" line correctly. This caused patches that had pathnames in no other places to be mistakenly rejected (most notably, binary patch that does not rename nor change mode). Textual patches, renames or mode changes have preimage and postimage pathnames in different places in a form that can be parsed unambiguously and did not suffer from this problem. * jc/apply-binary-p0: apply: compute patch->def_name correctly under -p0
2012-08-25apply: compute patch->def_name correctly under -p0Junio C Hamano
Back when "git apply" was written, we made sure that the user can skip more than the default number of path components (i.e. 1) by giving "-p<n>", but the logic for doing so was built around the notion of "we skip N slashes and stop". This obviously does not work well when running under -p0 where we do not want to skip any, but still want to skip SP/HT that separates the pathnames of preimage and postimage and want to reject absolute pathnames. Stop using "stop_at_slash()", and instead introduce a new helper "skip_tree_prefix()" with similar logic but works correctly even for the -p0 case. This is an ancient bug, but has been masked for a long time because most of the patches are text and have other clues to tell us the name of the preimage and the postimage. Noticed by Colin McCabe. Signed-off-by: Junio C Hamano <>
2012-06-25tests: enclose $PERL_PATH in double quotesJunio C Hamano
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 <>
2012-06-12t: Replace 'perl' by $PERL_PATHVincent van Ravesteijn
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 <> Signed-off-by: Junio C Hamano <>
2010-11-24Merge branch 'en/and-cascade-tests'Junio C Hamano
* en/and-cascade-tests: (25 commits) t4124 (apply --whitespace): use test_might_fail t3404: do not use 'describe' to implement test_cmp_rev t3404 (rebase -i): introduce helper to check position of HEAD t3404 (rebase -i): move comment to description t3404 (rebase -i): unroll test_commit loops t3301 (notes): use test_expect_code for clarity t1400 (update-ref): use test_must_fail t1502 (rev-parse --parseopt): test exit code from "-h" t6022 (renaming merge): chain test commands with && test-lib: introduce test_line_count to measure files tests: add missing &&, batch 2 tests: add missing && Introduce sane_unset and use it to ensure proper && chaining t7800 (difftool): add missing && t7601 (merge-pull-config): add missing && t7001 (mv): add missing && t6016 (rev-list-graph-simplify-history): add missing && t5602 (clone-remote-exec): add missing && t4026 (color): remove unneeded and unchained command t4019 (diff-wserror): add lots of missing && ... Conflicts: t/
2010-11-09tests: add missing &&Jonathan Nieder
Breaks in a test assertion's && chain can potentially hide failures from earlier commands in the chain. Commands intended to fail should be marked with !, test_must_fail, or test_might_fail. The examples in this patch do not require that. Signed-off-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2010-10-29apply: don't segfault on binary files with missing dataJeff King
Usually when applying a binary diff generated without --binary, it will be rejected early, as we don't even have the full sha1 of the pre- and post-images. However, if the diff is generated with --full-index (but not --binary), then we will actually try to apply it. If we have the postimage blob, then we can take a shortcut and never even look at the binary diff at all (e.g., this can happen when rebasing changes within a repository). If we don't have the postimage blob, though, we try to look at the actual fragments, of which there are none, and get a segfault. This patch checks explicitly for that case and complains to the user instead of segfaulting. We need to keep the check at a low level so that the "shortcut" case above continues to work. We also add a test that demonstrates the segfault. While we're at it, let's also explicitly test the shortcut case. Reported-by: Rafaël Carré <> Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2010-03-20Use test_expect_success for test setupsBrian Gernhardt
Several tests did not use test_expect_success for their setup commands. Putting these start commands into the testing framework means both that errors during setup will be caught quickly and that non-error text will be suppressed without -v. Signed-off-by: Brian Gernhardt <> Signed-off-by: Junio C Hamano <>
2008-09-03tests: use "git xyzzy" form (t3600 - t6999)Nanako Shiraishi
Converts tests between t3600-t6300. Signed-off-by: Nanako Shiraishi <> Signed-off-by: Junio C Hamano <>
2008-07-13t/: Use "test_must_fail git" instead of "! git"Stephan Beyer
This patch changes every occurrence of "! git" -- with the meaning that a git call has to gracefully fail -- into "test_must_fail git". This is useful to - make sure the test does not fail because of a signal, e.g. SIGSEGV, and - advertise the use of "test_must_fail" for new tests. Signed-off-by: Stephan Beyer <> Signed-off-by: Junio C Hamano <>
2008-03-13more tr portability test script fixesJeff King
Dealing with NULs is not always safe with tr. On Solaris, incoming NULs are silently deleted by both the System V and UCB versions of tr. When converting to NULs, the System V version works fine, but the UCB version silently ignores the request to convert the character. This patch changes all instances of tr using NULs to use "perl -pe 'y///'" instead. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2008-02-02Sane use of test_expect_failureJunio C Hamano
Originally, test_expect_failure was designed to be the opposite of test_expect_success, but this was a bad decision. Most tests run a series of commands that leads to the single command that needs to be tested, like this: test_expect_{success,failure} 'test title' ' setup1 && setup2 && setup3 && what is to be tested ' And expecting a failure exit from the whole sequence misses the point of writing tests. Your setup$N that are supposed to succeed may have failed without even reaching what you are trying to test. The only valid use of test_expect_failure is to check a trivial single command that is expected to fail, which is a minority in tests of Porcelain-ish commands. This large-ish patch rewrites all uses of test_expect_failure to use test_expect_success and rewrites the condition of what is tested, like this: test_expect_success 'test title' ' setup1 && setup2 && setup3 && ! this command should fail ' test_expect_failure is redefined to serve as a reminder that that test *should* succeed but due to a known breakage in git it currently does not pass. So if git-foo command should create a file 'bar' but you discovered a bug that it doesn't, you can write a test like this: test_expect_failure 'git-foo should create bar' ' rm -f bar && git foo && test -f bar ' This construct acts similar to test_expect_success, but instead of reporting "ok/FAIL" like test_expect_success does, the outcome is reported as "FIXED/still broken". Signed-off-by: Junio C Hamano <>
2007-12-18the use of 'tr' in the test suite isn't really portableH.Merijn Brand
Some versions of 'tr' only accept octal codes if entered with three digits, and therefor misinterpret the '\0' in the test suite. Some versions of 'tr' reject the (needless) use of character classes. Signed-off-by: H.Merijn Brand <> Signed-off-by: Junio C Hamano <>
2007-07-03Rewrite "git-frotz" to "git frotz"Junio C Hamano
This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <>
2006-09-07Make apply --binary a no-op.Junio C Hamano
Historically we did not allow binary patch applied without an explicit permission from the user, and this flag was the way to do so. This makes the flag a no-op by always allowing binary patch application. Signed-off-by: Junio C Hamano <>
2006-07-28t4103: fix binary patch application test.Junio C Hamano
The generated binary patch was _not_ binary -- earlier I made the --full-index flag to imply binary patch generation to the diff machinery, but later we made it independent from --binary (although the latter implies the former). Signed-off-by: Junio C Hamano <>
2005-12-20tests: make scripts executableJunio C Hamano
just for consistency. Signed-off-by: Junio C Hamano <>
2005-11-17tests: binary diff application.Junio C Hamano
This adds more tests to cover cases where binary diff application succeeds. Signed-off-by: Junio C Hamano <>
2005-11-17apply: allow-binary-replacement.Junio C Hamano
A new option, --allow-binary-replacement, is introduced. When you feed a diff that records full SHA1 name of pre- and post-image blob on its index line to git-apply with this option, the post-image blob replaces the path if what you have in the working tree matches the pre-image _and_ post-image blob is already available in the object directory. Later we _might_ want to enhance the diff output to also include the full binary data of the post-image, to make this more useful, but this is good enough for local rebasing application. Signed-off-by: Junio C Hamano <>
2005-11-16git-apply: fail if a patch cannot be applied.Junio C Hamano
Recently we fixed 'git-apply --stat' not to barf on a binary differences. But it accidentally broke the error detection when we actually attempt to apply them. This commit fixes the problem and adds test cases. Signed-off-by: Junio C Hamano <>