summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2021-12-09t2501: add various tests for removing the current working directoryLibravatar Elijah Newren1-0/+342
Numerous commands will remove directories left empty as a "convenience" after removing files within them. That is normally fine, but removing the current working directory can be rather inconvenient since it can cause confusion for the user when they run subsequent commands. For example, after one git process has removed the current working directory, git status/log/diff will all abort with the message: fatal: Unable to read current working directory: No such file or directory We also have code paths that, when a file needs to be placed where a directory is (due to e.g. checkout, merge, reset, whatever), will check if this is okay and error out if not. These rules include: * all tracked files under that directory are intended to be removed by the operation * none of the tracked files under that directory have uncommitted modification * there are no untracked files under that directory However, if we end up remove the current working directory, we can cause user confusion when they run subsequent commands, so we would prefer if there was a fourth rule added to this list: avoid removing the current working directory. Since there are several code paths that can result in the current working directory being removed, add several tests of various different codepaths. To make it clearer what the difference between the current behavior and the behavior at the end of the series, code both of them into the tests and have the appropriate behavior be selected by a flag. Subsequent commits will toggle the flag from current to desired behavior. Also add a few tests suggested during the review of earlier rounds of this patch series. Acked-by: Derrick Stolee <stolee@gmail.com> Acked-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-12Merge branch 'ab/fsck-unexpected-type'Libravatar Junio C Hamano1-0/+8
Regression fix. * ab/fsck-unexpected-type: object-file: free(*contents) only in read_loose_object() caller object-file: fix SEGV on free() regression in v2.34.0-rc2
2021-11-12Merge branch 'ps/connectivity-optim'Libravatar Junio C Hamano1-31/+0
Regression fix. * ps/connectivity-optim: Revert "connected: do not sort input revisions"
2021-11-11Revert "connected: do not sort input revisions"Libravatar Junio C Hamano1-31/+0
This reverts commit f45022dc2fd692fd024f2eb41a86a66f19013d43, as this is like breakage in the traversal more likely. In a history with 10 single strand of pearls, 1-->2-->3--...->7-->8-->9-->10 asking "rev-list --unsorted-input 1 10 --not 9 8 7 6 5 4" fails to paint the bottom 1 uninteresting as the traversal stops, without completing the propagation of uninteresting bit starting at 4 down through 3 and 2 to 1.
2021-11-11object-file: fix SEGV on free() regression in v2.34.0-rc2Libravatar Ævar Arnfjörð Bjarmason1-0/+8
Fix a regression introduced in my 96e41f58fe1 (fsck: report invalid object type-path combinations, 2021-10-01). When fsck-ing blobs larger than core.bigFileThreshold, we'd free() a pointer to uninitialized memory. This issue would have been caught by SANITIZE=address, but since it involves core.bigFileThreshold, none of the existing tests in our test suite covered it. Running them with the "big_file_threshold" in "environment.c" changed to say "6" would have shown this failure, but let's add a dedicated test for this scenario based on Han Xin's report[1]. The bug was introduced between v9 and v10[2] of the fsck series merged in 061a21d36d8 (Merge branch 'ab/fsck-unexpected-type', 2021-10-25). 1. https://lore.kernel.org/git/20211111030302.75694-1-hanxin.hx@alibaba-inc.com/ 2. https://lore.kernel.org/git/cover-v10-00.17-00000000000-20211001T091051Z-avarab@gmail.com/ Reported-by: Han Xin <chiyutianyi@gmail.com> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-10Merge branch 'jk/ssh-signing-fix'Libravatar Junio C Hamano1-0/+6
Reject OpenSSH 8.7 whose "ssh-keygen -Y find-principals" is unusable from running the ssh signature tests. * jk/ssh-signing-fix: t/lib-gpg: avoid broken versions of ssh-keygen
2021-11-10Merge branch 'jc/fix-pull-ff-only-when-already-up-to-date'Libravatar Junio C Hamano1-1/+15
"git pull --ff-only" and "git pull --rebase --ff-only" should make it a no-op to attempt pulling from a remote that is behind us, but instead the command errored out by saying it was impossible to fast-forward, which may technically be true, but not a useful thing to diagnose as an error. This has been corrected. * jc/fix-pull-ff-only-when-already-up-to-date: pull: --ff-only should make it a noop when already-up-to-date
2021-11-10t/lib-gpg: avoid broken versions of ssh-keygenLibravatar Jeff King1-0/+6
The "-Y find-principals" option of ssh-keygen seems to be broken in Debian's openssh-client 1:8.7p1-1, whereas it works fine in 1:8.4p1-5. This causes several failures for GPGSSH tests. We fulfill the prerequisite because generating the keys works fine, but actually verifying a signature causes results ranging from bogus results to ssh-keygen segfaulting. We can find the broken version during the prereq check by feeding it empty input. This should result in it complaining to stderr, but in the broken version it triggers the segfault, causing the GPGSSH tests to be skipped. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-09Merge branch 'ad/ssh-signing-testfix'Libravatar Junio C Hamano1-0/+1
Fix ssh-signing test to work on a platform where the default ACL is overly loose to upset OpenSSH (reported on an installation of Cygwin). * ad/ssh-signing-testfix: t/lib-git.sh: fix ACL-related permissions failure
2021-11-05t/lib-git.sh: fix ACL-related permissions failureLibravatar Adam Dinwoodie1-0/+1
As well as checking that the relevant functionality is available, the GPGSSH prerequisite check creates the SSH keys that are used by the test functions it gates. If these keys are created in a directory that has a default Access Control List, the key files can inherit those permissions. This can result in a scenario where the private keys are created successfully, so the prerequisite check passes and the tests are run, but the key files have permissions that are too permissive, meaning OpenSSH will refuse to load them and the tests will fail. To avoid this happening, before creating the keys, clear any default ACL set on the directory that will contain them. This step allowed to fail; if setfacl isn't present, that's a very likely indicator that the filesystem in question simply doesn't support default ACLs. Helped-by: Fabian Stelzer <fs@gigacodes.de> Signed-off-by: Adam Dinwoodie <adam@dinwoodie.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-04Merge branch 'ar/no-verify-doc'Libravatar Junio C Hamano1-0/+8
Doc update. * ar/no-verify-doc: Document positive variant of commit and merge option "--no-verify"
2021-11-04Merge branch 'ar/fix-git-pull-no-verify'Libravatar Junio C Hamano1-0/+24
"git pull --no-verify" did not affect the underlying "git merge". * ar/fix-git-pull-no-verify: pull: honor --no-verify and do not call the commit-msg hook
2021-11-03Merge branch 'pw/rebase-r-fixes'Libravatar Junio C Hamano1-0/+29
Regression fix. * pw/rebase-r-fixes: rebase -i: fix rewording with --committer-date-is-author-date
2021-11-03Merge branch 'ds/add-rm-with-sparse-index'Libravatar Junio C Hamano1-0/+26
Regression fix. * ds/add-rm-with-sparse-index: dir: fix directory-matching bug
2021-11-03rebase -i: fix rewording with --committer-date-is-author-dateLibravatar Phillip Wood1-0/+29
baf8ec8d3a (rebase -r: don't write .git/MERGE_MSG when fast-forwarding, 2021-08-20) stopped reading the author script in run_git_commit() when rewording a commit. This is normally safe because "git commit --amend" preserves the authorship. However if the user passes "--committer-date-is-author-date" then we need to read the author date from the author script when rewording. Fix this regression by tightening the check for when it is safe to skip reading the author script. Reported-by: Jonas Kittner <jonas.kittner@ruhr-uni-bochum.de> Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-03dir: fix directory-matching bugLibravatar Derrick Stolee1-0/+26
This reverts the change from ed49584 (dir: fix pattern matching on dirs, 2021-09-24), which claimed to fix a directory-matching problem without a test case. It turns out to _create_ a bug, but it is a bit subtle. The bug would have been revealed by the first of two tests being added to t0008-ignores.sh. The first uses a pattern "/git/" inside the a/.gitignores file, which matches against 'a/git/foo' but not 'a/git-foo/bar'. This test would fail before the revert. The second test shows what happens if the test instead uses a pattern "git/" and this test passes both before and after the revert. The difference in these two cases are due to how last_matching_pattern_from_list() checks patterns both if they have the PATTERN_FLAG_MUSTBEDIR and PATTERN_FLAG_NODIR flags. In the case of "git/", the PATTERN_FLAG_NODIR is also provided, making the change in behavior in match_pathname() not affect the end result of last_matching_pattern_from_list(). Reported-by: Glen Choo <chooglen@google.com> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-01Merge branch 'ab/test-lib'Libravatar Junio C Hamano1-1/+0
Test (cosmetic) fix. * ab/test-lib: t5310: drop lib-bundle.sh include
2021-11-01Merge branch 'gc/use-repo-settings'Libravatar Junio C Hamano4-7/+55
It is wrong to read some settings directly from the config subsystem, as things like feature.experimental can affect their default values. * gc/use-repo-settings: gc: perform incremental repack when implictly enabled fsck: verify multi-pack-index when implictly enabled fsck: verify commit graph when implicitly enabled
2021-11-01Merge branch 'ab/ignore-replace-while-working-on-commit-graph'Libravatar Junio C Hamano2-10/+15
Teach "git commit-graph" command not to allow using replace objects at all, as we do not use the commit-graph at runtime when we see object replacement. * ab/ignore-replace-while-working-on-commit-graph: commit-graph: don't consider "replace" objects with "verify" commit-graph tests: fix another graph_git_two_modes() helper commit-graph tests: fix error-hiding graph_git_two_modes() helper
2021-11-01Merge branch 'hm/paint-hits-in-log-grep'Libravatar Junio C Hamano2-0/+99
"git log --grep=string --author=name" learns to highlight hits just like "git grep string" does. * hm/paint-hits-in-log-grep: grep/pcre2: fix an edge case concerning ascii patterns and UTF-8 data pretty: colorize pattern matches in commit messages grep: refactor next_match() and match_one_pattern() for external use
2021-10-29Merge branch 'mt/fix-add-rm-with-sparse-index'Libravatar Junio C Hamano3-5/+73
Fix-up to a topic already merged to 'master'. * mt/fix-add-rm-with-sparse-index: add, rm, mv: fix bug that prevents the update of non-sparse dirs
2021-10-29Merge branch 'jk/log-warn-on-bogus-encoding'Libravatar Junio C Hamano1-7/+0
Squelch over-eager warning message added during this cycle. * jk/log-warn-on-bogus-encoding: log: document --encoding behavior on iconv() failure Revert "logmsg_reencode(): warn when iconv() fails"
2021-10-29Merge branch 'ab/plug-random-leaks'Libravatar Junio C Hamano1-1/+2
Leakfix. * ab/plug-random-leaks: reflog: free() ref given to us by dwim_log() submodule--helper: fix small memory leaks clone: fix a memory leak of the "git_dir" variable grep: fix a "path_list" memory leak grep: use object_array_clear() in cmd_grep() grep: prefer "struct grep_opt" over its "void *" equivalent
2021-10-29Merge branch 'ab/plug-handle-path-exclude-leak'Libravatar Junio C Hamano1-0/+1
Leakfix. * ab/plug-handle-path-exclude-leak: config.c: don't leak memory in handle_path_include()
2021-10-29Merge branch 'jk/http-push-status-fix'Libravatar Junio C Hamano4-0/+27
"git push" client talking to an HTTP server did not diagnose the lack of the final status report from the other side correctly, which has been corrected. * jk/http-push-status-fix: transport-helper: recognize "expecting report" error from send-pack send-pack: complain about "expecting report" with --helper-status
2021-10-29Merge branch 'ab/test-bail'Libravatar Junio C Hamano1-7/+21
A new feature has been added to abort early in the test framework. * ab/test-bail: test-lib.sh: use "Bail out!" syntax on bad SANITIZE=leak use test-lib.sh: de-duplicate error() teardown code
2021-10-29Revert "logmsg_reencode(): warn when iconv() fails"Libravatar Junio C Hamano1-7/+0
This reverts commit fd680bc5 (logmsg_reencode(): warn when iconv() fails, 2021-08-27). Throwing a warning for each and every commit that gets reencoded, without allowing a way to squelch, would make it unpleasant for folks who have to deal with an ancient part of the history in an old project that used wrong encoding in the commits.
2021-10-29Document positive variant of commit and merge option "--no-verify"Libravatar Alex Riesen1-0/+8
This documents "--verify" option of the commands. It can be used to re-enable the hooks disabled by an earlier "--no-verify" in command-line. Signed-off-by: Alexander Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-29pull: --ff-only should make it a noop when already-up-to-dateLibravatar Junio C Hamano1-1/+15
Earlier, we made sure that "git pull --ff-only" (and "git -c pull.ff=only pull") errors out when our current HEAD is not an ancestor of the tip of the history we are merging, but the condition to trigger the error was implemented incorrectly. Imagine you forked from a remote branch, built your history on top of it, and then attempted to pull from them again. If they have not made any update in the meantime, our current HEAD is obviously not their ancestor, and this new error triggers. Without the --ff-only option, we just report that there is no need to pull; we did the same historically with --ff-only, too. Make sure we do not fail with the recently added check to restore the historical behaviour. Reported-by: Kenneth Arnold <ka37@calvin.edu> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-29t5310: drop lib-bundle.sh includeLibravatar Jeff King1-1/+0
Commit ddfe900612 (test-lib-functions: move function to lib-bitmap.sh, 2021-02-09) meant to include lib-bitmap.sh in t5310, but also includes lib-bundle.sh. Yet we don't use any of its functions, nor have anything to do with bundles. This is probably just a typo/copy-paste error, as lib-bundle.sh was added (correctly) to other scripts in the same series. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-28pull: honor --no-verify and do not call the commit-msg hookLibravatar Alex Riesen1-0/+24
The option was incorrectly auto-translated to "--no-verify-signatures", which causes the unexpected effect of the hook being called. And an even more unexpected effect of disabling verification of signatures. The manual page describes the option to behave same as the similarly named option of "git merge", which seems to be the original intention of this option in the "pull" command. Signed-off-by: Alexander Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-28add, rm, mv: fix bug that prevents the update of non-sparse dirsLibravatar Matheus Tavares3-5/+73
These three commands recently learned to avoid updating paths outside the sparse checkout even if they are missing the SKIP_WORKTREE bit. This is done using path_in_sparse_checkout(), which checks whether a given path matches the current list of sparsity rules, similar to what clear_ce_flags() does when we run "git sparse checkout init" or "git sparse-checkout reapply". However, clear_ce_flags() uses a recursive approach, applying the match results from parent directories on paths that get the UNDECIDED result, whereas path_in_sparse_checkout() only attempts to match the full path and immediately considers UNDECIDED as NOT_MATCHED. This makes the function miss matches with leading directories. For example, if the user has the sparsity patterns "!/a" and "b/", add, rm, and mv will fail to update the path "a/b/c" and end up displaying a warning about it being outside the sparse checkout even though it isn't. This problem only occurs in full pattern mode as the pattern matching functions never return UNDECIDED for cone mode. To fix this, replicate the recursive behavior of clear_ce_flags() in path_in_sparse_checkout(), falling back to the parent directory match when a path gets the UNDECIDED result. (If this turns out to be too expensive in some cases, we may want to later add some form of caching to accelerate multiple queries within the same directory. This is not implemented in this patch, though.) Also add two tests for each affected command (add, rm, and mv) to check that they behave correctly with the recursive pattern matching. The first test would previously fail without this patch while the second already succeeded. It is added mostly to make sure that we are not breaking the existing pattern matching for directories that are really sparse, and also as a protection against any future regressions. Two other existing tests had to be changed as well: one test in t3602 checks that "git rm -r <dir>" won't remove sparse entries, but it didn't allow the non-sparse entries inside <dir> to be removed. The other one, in t7002, tested that "git mv" would correctly display a warning message for sparse paths, but it accidentally expected the message to include two non-sparse paths as well. Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br> Acked-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-25Merge branch 'ab/test-lib-diff-cleanup'Libravatar Junio C Hamano14-433/+53
Test clean-up. * ab/test-lib-diff-cleanup: tests: stop using top-level "README" and "COPYING" files "lib-diff" tests: make "README" and "COPYING" test data smaller
2021-10-25Merge branch 'ab/test-cleanly-recreate-trash-directory'Libravatar Junio C Hamano1-1/+13
Improve test framework around unwritable directories. * ab/test-cleanly-recreate-trash-directory: test-lib.sh: try to re-chmod & retry on failed trash removal
2021-10-25Merge branch 'ab/mark-leak-free-tests-more'Libravatar Junio C Hamano14-3/+30
Bunch of tests are marked as "passing leak check". * ab/mark-leak-free-tests-more: merge: add missing strbuf_release() ls-files: add missing string_list_clear() ls-files: fix a trivial dir_clear() leak tests: fix test-oid-array leak, test in SANITIZE=leak tests: fix a memory leak in test-oidtree.c tests: fix a memory leak in test-parse-options.c tests: fix a memory leak in test-prio-queue.c
2021-10-25Merge branch 'ab/mark-leak-free-tests'Libravatar Junio C Hamano66-0/+86
Bunch of tests are marked as "passing leak check". * ab/mark-leak-free-tests: leak tests: mark some misc tests as passing with SANITIZE=leak leak tests: mark various "generic" tests as passing with SANITIZE=leak leak tests: mark some read-tree tests as passing with SANITIZE=leak leak tests: mark some ls-files tests as passing with SANITIZE=leak leak tests: mark all checkout-index tests as passing with SANITIZE=leak leak tests: mark all trace2 tests as passing with SANITIZE=leak leak tests: mark all ls-tree tests as passing with SANITIZE=leak leak tests: run various "test-tool" tests in t00*.sh SANITIZE=leak leak tests: run various built-in tests in t00*.sh SANITIZE=leak
2021-10-25Merge branch 'ab/parse-options-cleanup'Libravatar Junio C Hamano1-3/+39
Random changes to parse-options implementation. * ab/parse-options-cleanup: parse-options: change OPT_{SHORT,UNSET} to an enum parse-options tests: test optname() output parse-options.[ch]: make opt{bug,name}() "static" commit-graph: stop using optname() parse-options.c: move optname() earlier in the file parse-options.h: make the "flags" in "struct option" an enum parse-options.c: use exhaustive "case" arms for "enum parse_opt_result" parse-options.[ch]: consistently use "enum parse_opt_result" parse-options.[ch]: consistently use "enum parse_opt_flags" parse-options.h: move PARSE_OPT_SHELL_EVAL between enums
2021-10-25Merge branch 'js/userdiff-cpp'Libravatar Junio C Hamano3-65/+86
Userdiff patterns for the C++ language has been updated. * js/userdiff-cpp: userdiff-cpp: back out the digit-separators in numbers userdiff-cpp: learn the C++ spaceship operator userdiff-cpp: permit the digit-separating single-quote in numbers userdiff-cpp: prepare test cases with yet unsupported features userdiff-cpp: tighten word regex t4034: add tests showing problematic cpp tokenizations t4034/cpp: actually test that operator tokens are not split
2021-10-25Merge branch 'fs/ssh-signing-fix'Libravatar Junio C Hamano1-0/+28
Fix-up for the other topic already in 'next'. * fs/ssh-signing-fix: gpg-interface: fix leak of strbufs in get_ssh_key_fingerprint() gpg-interface: fix leak of "line" in parse_ssh_output() ssh signing: clarify trustlevel usage in docs ssh signing: fmt-merge-msg tests & config parse
2021-10-25Merge branch 'fs/ssh-signing'Libravatar Junio C Hamano6-1/+739
Use ssh public crypto for object and push-cert signing. * fs/ssh-signing: ssh signing: test that gpg fails for unknown keys ssh signing: tests for logs, tags & push certs ssh signing: duplicate t7510 tests for commits ssh signing: verify signatures using ssh-keygen ssh signing: provide a textual signing_key_id ssh signing: retrieve a default key from ssh-agent ssh signing: add ssh key format and signing code ssh signing: add test prereqs ssh signing: preliminary refactoring and clean-up
2021-10-25Merge branch 'pw/sparse-cache-tree-verify-fix'Libravatar Junio C Hamano1-1/+1
Recent sparse-index addition, namely any use of index_name_pos(), can expand sparse index entries and breaks any code that walks cache-tree or existing index entries. One such instance of such a breakage has been corrected. * pw/sparse-cache-tree-verify-fix: t1092: run "rebase --apply" without "-q" in testing sparse index: fix use-after-free bug in cache_tree_verify()
2021-10-25Merge branch 'ab/fix-commit-error-message-upon-unwritable-object-store'Libravatar Junio C Hamano1-4/+43
"git commit" gave duplicated error message when the object store was unwritable, which has been corrected. * ab/fix-commit-error-message-upon-unwritable-object-store: commit: fix duplication regression in permission error output unwritable tests: assert exact error output
2021-10-25Merge branch 'rs/add-dry-run-without-objects'Libravatar Junio C Hamano1-0/+3
Stop "git add --dry-run" from creating new blob and tree objects. * rs/add-dry-run-without-objects: add: don't write objects with --dry-run
2021-10-25Merge branch 'rs/disable-gc-during-perf-tests'Libravatar Junio C Hamano2-0/+6
Avoid performance measurements from getting ruined by gc and other housekeeping pauses interfering in the middle. * rs/disable-gc-during-perf-tests: perf: disable automatic housekeeping
2021-10-25Merge branch 'jt/no-abuse-alternate-odb-for-submodules'Libravatar Junio C Hamano7-5/+20
Follow through the work to use the repo interface to access submodule objects in-process, instead of abusing the alternate object database interface. * jt/no-abuse-alternate-odb-for-submodules: submodule: trace adding submodule ODB as alternate submodule: pass repo to check_has_commit() object-file: only register submodule ODB if needed merge-{ort,recursive}: remove add_submodule_odb() refs: peeling non-the_repository iterators is BUG refs: teach arbitrary repo support to iterators refs: plumb repo into ref stores
2021-10-25Merge branch 'ab/unpack-trees-leakfix'Libravatar Junio C Hamano1-0/+2
Leakfix. * ab/unpack-trees-leakfix: sequencer: fix a memory leak in do_reset() sequencer: add a "goto cleanup" to do_reset() unpack-trees: don't leak memory in verify_clean_subdirectory()
2021-10-25Merge branch 'jh/perf-remove-test-times'Libravatar Junio C Hamano1-0/+1
Perf test fix. * jh/perf-remove-test-times: t/perf/perf-lib.sh: remove test_times.* at the end test_perf_()
2021-10-25Merge branch 'ab/fsck-unexpected-type'Libravatar Junio C Hamano3-36/+291
"git fsck" has been taught to report mismatch between expected and actual types of an object better. * ab/fsck-unexpected-type: fsck: report invalid object type-path combinations fsck: don't hard die on invalid object types object-file.c: stop dying in parse_loose_header() object-file.c: return ULHR_TOO_LONG on "header too long" object-file.c: use "enum" return type for unpack_loose_header() object-file.c: simplify unpack_loose_short_header() object-file.c: make parse_loose_header_extended() public object-file.c: return -1, not "status" from unpack_loose_header() object-file.c: don't set "typep" when returning non-zero cat-file tests: test for current --allow-unknown-type behavior cat-file tests: add corrupt loose object test cat-file tests: test for missing/bogus object with -t, -s and -p cat-file tests: move bogus_* variable declarations earlier fsck tests: test for garbage appended to a loose object fsck tests: test current hash/type mismatch behavior fsck tests: refactor one test to use a sub-repo fsck tests: add test for fsck-ing an unknown type
2021-10-25userdiff-cpp: back out the digit-separators in numbersLibravatar Johannes Sixt3-15/+15
The implementation of digit-separating single-quotes introduced a note-worthy regression: the change of a character literal with a digit would splice the digit and the closing single-quote. For example, the change from 'a' to '2' is now tokenized as '[-a'-]{+2'+} instead of '[-a-]{+2+}'. The options to fix the regression are: - Tighten the regular expression such that the single-quote can only occur between digits (that would match the official syntax). - Remove support for digit separators. I chose to remove support, because - I have not seen a lot of code make use of digit separators. - If code does use digit separators, then the numbers are typically long. If a change in one of the segments occurs, it is actually better visible if only that segment is highlighted as the word that changed instead of the whole long number. This choice does introduce another minor regression, though, which is highlighted in the test case: when a change occurs in the second or later segment of a hexadecimal number where the segment begins with a digit, but also has letters, the segment is mistaken as consisting of a number and an identifier. I can live with that. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-23grep: fix a "path_list" memory leakLibravatar Ævar Arnfjörð Bjarmason1-1/+2
Free the "path_list" used in builtin/grep.c, it was declared as STRING_LIST_INIT_NODUP, let's change it to a STRING_LIST_INIT_DUP since an early user in cmd_grep() appends a string passed via parse-options.c to it, which needs to be duplicated. Let's then convert the remaining callers to use string_list_append_nodup() instead, allowing us to free the list. This makes all the tests in t7811-grep-open.sh pass, 6/10 would fail before this change. The only remaining failure would have been due to a stray "git checkout" (which still leaks memory). In this case we can use a "git reset --hard" instead, so let's do that, and move the test_when_finished() above the code that would modify the relevant file. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>