summaryrefslogtreecommitdiff
path: root/t/t4209-log-pickaxe.sh
AgeCommit message (Collapse)AuthorFilesLines
2021-05-11pickaxe -S: support content with NULs under --pickaxe-regexLibravatar Ævar Arnfjörð Bjarmason1-0/+8
Fix a bug in the matching routine powering -S<rx> --pickaxe-regex so that we won't abort early on content that has NULs in it. We've had a hard requirement on REG_STARTEND since 2f8952250a8 (regex: add regexec_buf() that can work on a non NUL-terminated string, 2016-09-21), but this sanity check dates back to d01d8c67828 (Support for pickaxe matching regular expressions, 2006-03-29). It wasn't needed anymore, and as the now-passing test shows, actively getting in our way. Since we always require REG_STARTEND support we do not need to stop at NULs. If we are dealing with a haystack with NUL in it. The needle may be behind that NUL. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-11pickaxe: assert that we must have a needle under -G or -SLibravatar Ævar Arnfjörð Bjarmason1-0/+6
Assert early in diffcore_pickaxe() that we've got a needle to work with under -G and -S. This code is redundant to the check -G and -S get from parse-options.c's get_arg(), which I'm adding a test for. This check dates back to e1b161161d (diffcore-pickaxe: fix infinite loop on zero-length needle, 2007-01-25) when "git log -S" could send this code into an infinite loop. It was then later refactored in 8fa4b09fb1 (pickaxe: hoist empty needle check, 2012-10-28) into its current form, but it seemingly wasn't noticed that in the meantime a move to the parse-options.c API in dea007fb4c (diff: parse separate options like -S foo, 2010-08-05) had made it redundant. Let's retain some of the paranoia here with a BUG(), but there's no need to be checking this in the pickaxe_match() inner loop. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-11pickaxe: die when --find-object and --pickaxe-all are combinedLibravatar Ævar Arnfjörð Bjarmason1-0/+3
Neither the --pickaxe-all documentation nor --find-object's has ever suggested that you can combine the two. See f506b8e8b5 (git log/diff: add -G<regexp> that greps in the patch text, 2010-08-23) and 15af58c1ad (diffcore: add a pickaxe option to find a specific blob, 2018-01-04). But we've silently tolerated it, which makes the logic in diffcore_pickaxe() harder to reason about. Let's assert that we won't have the two combined. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-11pickaxe: die when -G and --pickaxe-regex are combinedLibravatar Ævar Arnfjörð Bjarmason1-0/+5
When the -G and --pickaxe-regex options are combined we simply ignore the --pickaxe-regex option. Let's die instead as suggested by our documentation, since -G is always a regex. When --pickaxe-regex was added in d01d8c6782 (Support for pickaxe matching regular expressions, 2006-03-29) only the -S option existed. Then when -G was added in f506b8e8b5 (git log/diff: add -G<regexp> that greps in the patch text, 2010-08-23) neither the documentation for --pickaxe-regex was updated accordingly, nor was something like this assertion added. Since 5bc3f0b567 (diffcore-pickaxe doc: document -S and -G properly, 2013-05-31) we've claimed that --pickaxe-regex should only be used with -S, but have silently tolerated combining it with -G, let's die instead. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-11pickaxe tests: add missing test for --no-pickaxe-regex being an errorLibravatar Ævar Arnfjörð Bjarmason1-0/+12
Add a missing test for --no-pickaxe-regex. This has been an error ever since before the -S or -G options were added, or since 7ae0b0cb65f (git-log (internal): more options., 2006-03-01). The reason for adding this test is that Junio suggested in [1] in response to a later test addition in this series that it might be good to support --no-pickaxe-regex in combination with -G. This would allow for fixed-string searching with -G, similr to grep's --fixed-strings mode. I agree that that would make sense if anyone would like to implement it, but since it dies right now let's first add this test to assert the existing long-standing behavior. We can always add support for --[no-]pickaxe-regex in combination with -G at some later date. 1. http://lore.kernel.org/git/xmqqwnto9pt7.fsf@gitster.g Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-11pickaxe tests: test for -G, -S and --find-object incompatibilityLibravatar Ævar Arnfjörð Bjarmason1-0/+11
Add a test for the options sanity check added in 5e505257f2 (diff: properly error out when combining multiple pickaxe options, 2018-01-04). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-11pickaxe tests: add test for "log -S" not being a regexLibravatar Ævar Arnfjörð Bjarmason1-3/+27
No test in our test suite checked for "log -S<pat>" being a fixed string, as opposed to "log -S<pat> --pickaxe-regex". Let's test for it. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-11pickaxe tests: add test for diffgrep_consume() internalsLibravatar Ævar Arnfjörð Bjarmason1-0/+15
In diffgrep_consume() we generate a diff, and then advance past the "+" or "-" at the start of the line for matching. This has been done ever since the code was added in f506b8e8b5f (git log/diff: add -G<regexp> that greps in the patch text, 2010-08-23). If we match "line" instead of "line + 1" no tests fail, i.e. we've got zero coverage for whether any of our searches match the beginning of the line or not. Let's add a test for this. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-11pickaxe tests: refactor to use test_commit --append --printfLibravatar Ævar Arnfjörð Bjarmason1-16/+14
Refactor the existing tests added in e0e7cb8080c (log -G: ignore binary files, 2018-12-14) to use the --append option I added in 3373518cc8b (test-lib functions: add an --append option to test_commit, 2021-01-12) and the --printf option added as part of an in-flight topic of mine this commit depends on. While I'm at it change some of the setup of the test to use a more sensible pattern, e.g. setting up a temporary repo instead of creating an orphan branch. Since the -G and -S options will behave the same way with truncated and removed content also change the "git rm" to emptying data.bin, that's just catering to how test_commit works. The resulting test is shorter. See also f5d79bf7dd6 (tests: refactor a few tests to use "test_commit --append", 2021-01-12) for prior similar refactoring. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-12-26log -G: ignore binary filesLibravatar Thomas Braun1-0/+35
The -G<regex> option of log looks for the differences whose patch text contains added/removed lines that match regex. Currently -G looks also into patches of binary files (which according to [1]) is binary as well. This has a couple of issues: - It makes the pickaxe search slow. In a proprietary repository of the author with only ~5500 commits and a total .git size of ~300MB searching takes ~13 seconds $time git log -Gwave > /dev/null real 0m13,241s user 0m12,596s sys 0m0,644s whereas when we ignore binary files with this patch it takes ~4s $time ~/devel/git/git log -Gwave > /dev/null real 0m3,713s user 0m3,608s sys 0m0,105s which is a speedup of more than fourfold. - The internally used algorithm for generating patch text is based on xdiff and its states in [1] > The output format of the binary patch file is proprietary > (and binary) and it is basically a collection of copy and insert > commands [..] which means that the current format could change once the internal algorithm is changed as the format is not standardized. In addition the git binary patch format used for preparing patches for git apply is *different* from the xdiff format as can be seen by comparing git log -p -a commit 6e95bf4bafccf14650d02ab57f3affe669be10cf Author: A U Thor <author@example.com> Date: Thu Apr 7 15:14:13 2005 -0700 modify binary file diff --git a/data.bin b/data.bin index f414c84..edfeb6f 100644 --- a/data.bin +++ b/data.bin @@ -1,2 +1,4 @@ a a^@a +a +a^@a with git log --binary commit 6e95bf4bafccf14650d02ab57f3affe669be10cf Author: A U Thor <author@example.com> Date: Thu Apr 7 15:14:13 2005 -0700 modify binary file diff --git a/data.bin b/data.bin index f414c84bd3aa25fa07836bb1fb73db784635e24b..edfeb6f501[..] GIT binary patch literal 12 QcmYe~N@Pgn0zx1O01)N^ZvX%Q literal 6 NcmYe~N@Pgn0ssWg0XP5v which seems unexpected. To resolve these issues this patch makes -G<regex> ignore binary files by default. Textconv filters are supported and also -a/--text for getting the old and broken behaviour back. The -S<block of text> option of log looks for differences that changes the number of occurrences of the specified block of text (i.e. addition/deletion) in a file. As we want to keep the current behaviour, add a test to ensure it stays that way. [1]: http://www.xmailserver.org/xdiff.html Signed-off-by: Thomas Braun <thomas.braun@virtuell-zuhause.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-24pickaxe: honor -i when used with -S and --pickaxe-regexLibravatar René Scharfe1-0/+5
accccde4 (pickaxe: allow -i to search in patch case-insensitively) allowed case-insenitive matching for -G and -S, but for the latter only if fixed string matching is used. Allow it for -S and regular expression matching as well to make the support complete. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-24t4209: use helper functions to test --authorLibravatar René Scharfe1-9/+4
Also add tests for case sensitive and non-matching cases. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-24t4209: use helper functions to test --grepLibravatar René Scharfe1-14/+4
Also add tests for non-matching cases. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-24t4209: factor out helper function test_log_icase()Libravatar René Scharfe1-12/+14
Reduce code duplication by introducing test_log_icase() that runs the same test with both --regexp-ignore-case and -i. The specification of the four basic test scenarios (matching/nomatching combined with case sensitive/insensitive) becomes easier to read and write. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-24t4209: factor out helper function test_log()Libravatar René Scharfe1-58/+42
Twelve tests in t4209 follow the same simple pattern for description, git log call and checking. Extract that shared logic into a helper function named test_log. Test specifications become a lot more compact, new tests can be added more easily. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-24t4209: set up expectations up frontLibravatar René Scharfe1-39/+25
Instead of creating an expect file for each test, build three files with the possible valid values during setup and use them in the tests. This shortens the test code and saves nine calls to git rev-parse. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-05diffcore-pickaxe: respect --no-textconvLibravatar Simon Ruderich1-0/+28
git log -S doesn't respect --no-textconv: $ echo '*.txt diff=wrong' > .gitattributes $ git -c diff.wrong.textconv='xxx' log --no-textconv -Sfoo error: cannot run xxx: No such file or directory fatal: unable to read files to diff Reported-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> Signed-off-by: Simon Ruderich <simon@ruderich.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-28pickaxe: allow -i to search in patch case-insensitivelyLibravatar Junio C Hamano1-0/+119
"git log -S<string>" is a useful way to find the last commit in the codebase that touched the <string>. As it was designed to be used by a porcelain script to dig the history starting from a block of text that appear in the starting commit, it never had to look for anything but an exact match. When used by an end user who wants to look for the last commit that removed a string (e.g. name of a variable) that he vaguely remembers, however, it is useful to support case insensitive match. When given the "--regexp-ignore-case" (or "-i") option, which originally was designed to affect case sensitivity of the search done in the commit log part, e.g. "log --grep", the matches made with -S/-G pickaxe search is done case insensitively now. Signed-off-by: Junio C Hamano <gitster@pobox.com>