aboutsummaryrefslogtreecommitdiffstats
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2021-12-02t1405: check for_each_reflog_ent_reverse() more thoroughlyHan-Wen Nienhuys1-0/+1
If we are checking for a certain ordering, we should check that there are two entries. Do this by mirroring the preceding test. Signed-off-by: Han-Wen Nienhuys <hanwen@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-02test-ref-store: don't add newline to reflog messageHan-Wen Nienhuys3-8/+6
By convention, reflog messages always end in '\n', so before we would print blank lines between entries. Signed-off-by: Han-Wen Nienhuys <hanwen@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-02show-branch: show reflog messageHan-Wen Nienhuys1-0/+15
Before, --reflog option would look for '\t' in the reflog message. As refs.c already parses the reflog line, the '\t' was never found, and show-branch --reflog would always say "(none)" as reflog message Add test. Signed-off-by: Han-Wen Nienhuys <hanwen@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-29Merge branch 'mc/clean-smudge-with-llp64'Junio C Hamano3-4/+47
The clean/smudge conversion code path has been prepared to better work on platforms where ulong is narrower than size_t. * mc/clean-smudge-with-llp64: clean/smudge: allow clean filters to process extremely large files odb: guard against data loss checking out a huge file git-compat-util: introduce more size_t helpers odb: teach read_blob_entry to use size_t t1051: introduce a smudge filter test for extremely large files test-lib: add prerequisite for 64-bit platforms test-tool genzeros: generate large amounts of data more efficiently test-genzeros: allow more than 2G zeros in Windows
2021-11-29Merge branch 'tb/plug-pack-bitmap-leaks'Junio C Hamano1-1/+2
Leakfix. * tb/plug-pack-bitmap-leaks: pack-bitmap.c: more aggressively free in free_bitmap_index() pack-bitmap.c: don't leak type-level bitmaps midx.c: write MIDX filenames to strbuf builtin/multi-pack-index.c: don't leak concatenated options builtin/repack.c: avoid leaking child arguments builtin/pack-objects.c: don't leak memory via arguments t/helper/test-read-midx.c: free MIDX within read_midx_file() midx.c: don't leak MIDX from verify_midx_file midx.c: clean up chunkfile after reading the MIDX
2021-11-29Merge branch 'tp/send-email-completion'Junio C Hamano1-0/+3
The command line complation for "git send-email" options have been tweaked to make it easier to keep it in sync with the command itself. * tp/send-email-completion: send-email docs: add format-patch options send-email: programmatically generate bash completions
2021-11-29Merge branch 'jc/fix-ref-sorting-parse'Junio C Hamano2-1/+37
Things like "git -c branch.sort=bogus branch new HEAD", i.e. the operation modes of the "git branch" command that do not need the sort key information, no longer errors out by seeing a bogus sort key. * jc/fix-ref-sorting-parse: for-each-ref: delay parsing of --sort=<atom> options
2021-11-29Merge branch 'so/stash-staged'Junio C Hamano1-0/+11
"git stash" learned the "--staged" option to stash away what has been added to the index (and nothing else). * so/stash-staged: stash: get rid of unused argument in stash_staged() stash: implement '--staged' option for 'push' and 'save'
2021-11-29Merge branch 'ab/refs-errno-cleanup'Junio C Hamano3-1/+89
The "remainder" of hn/refs-errno-cleanup topic. * ab/refs-errno-cleanup: (21 commits) refs API: post-migration API renaming [2/2] refs API: post-migration API renaming [1/2] refs API: don't expose "errno" in run_transaction_hook() refs API: make expand_ref() & repo_dwim_log() not set errno refs API: make resolve_ref_unsafe() not set errno refs API: make refs_ref_exists() not set errno refs API: make refs_resolve_refdup() not set errno refs tests: ignore ignore errno in test-ref-store helper refs API: ignore errno in worktree.c's find_shared_symref() refs API: ignore errno in worktree.c's add_head_info() refs API: make files_copy_or_rename_ref() et al not set errno refs API: make loose_fill_ref_dir() not set errno refs API: make resolve_gitlink_ref() not set errno refs API: remove refs_read_ref_full() wrapper refs/files: remove "name exist?" check in lock_ref_oid_basic() reflog tests: add --updateref tests refs API: make refs_rename_ref_available() static refs API: make parse_loose_ref_contents() not set errno refs API: make refs_read_raw_ref() not set errno refs API: add a version of refs_resolve_ref_unsafe() with "errno" ...
2021-11-29Merge branch 'ow/stash-count-in-status-porcelain-output'Junio C Hamano1-0/+15
Allow "git status --porcelain=v2" to show the number of stash entries with --show-stash like the normal output does. * ow/stash-count-in-status-porcelain-output: status: print stash info with --porcelain=v2 --show-stash status: count stash entries in separate function
2021-11-29Merge branch 'jk/loosen-urlmatch'Junio C Hamano1-1/+1
Treat "_" as any other URL-valid characters in an URL when matching the per-URL configuration variable names. * jk/loosen-urlmatch: urlmatch: add underscore to URL_HOST_CHARS
2021-11-22Merge branch 'ds/add-rm-with-sparse-index'Junio C Hamano1-0/+17
Regression fix for 2.34 * ds/add-rm-with-sparse-index: dir: revert "dir: select directories correctly"
2021-11-22dir: revert "dir: select directories correctly"Derrick Stolee1-0/+17
This reverts commit f6526728f950cacfd5b5e42bcc65f2c47f3da654. The change in f652672 (dir: select directories correctly, 2021-09-24) caused a regression in directory-based matches with non-cone-mode patterns, especially for .gitignore patterns. A test is included to prevent this regression in the future. The commit ed495847 (dir: fix pattern matching on dirs, 2021-09-24) was reverted in 5ceb663 (dir: fix directory-matching bug, 2021-11-02) for similar reasons. Neither commit changed tests, and tests added later in the series continue to pass when these commits are reverted. Reported-by: Danial Alihosseini <danial.alihosseini@gmail.com> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-21Merge branch 'ev/pull-already-up-to-date-is-noop'Junio C Hamano1-0/+6
"git pull" with any strategy when the other side is behind us should succeed as it is a no-op, but doesn't. * ev/pull-already-up-to-date-is-noop: pull: should be noop when already-up-to-date
2021-11-21Merge branch 'hm/paint-hits-in-log-grep'Junio C Hamano1-48/+0
"git grep" looking in a blob that has non-UTF8 payload was completely broken when linked with certain versions of PCREv2 library in the latest release. * hm/paint-hits-in-log-grep: Revert "grep/pcre2: fix an edge case concerning ascii patterns and UTF-8 data"
2021-11-19Revert "grep/pcre2: fix an edge case concerning ascii patterns and UTF-8 data"Junio C Hamano1-48/+0
This reverts commit ae39ba431ab861548eb60b4bd2e1d8b8813db76f, as it breaks "grep" when looking for a string in non UTF-8 haystack, when linked with certain versions of PCREv2 library. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-18pull: should be noop when already-up-to-dateErwin Villejo1-0/+6
The already-up-to-date pull bug was fixed for --ff-only but it did not include the case where --ff or --ff-only are not specified. This updates the --ff-only fix to include the case where --ff or --ff-only are not specified in command line flags or config. Signed-off-by: Erwin Villejo <erwin.villejo@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-12Merge branch 'ab/fsck-unexpected-type'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'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"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-rc2Æ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'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'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-keygenJeff 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'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 failureAdam 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'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'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'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'Junio C Hamano1-0/+26
Regression fix. * ds/add-rm-with-sparse-index: dir: fix directory-matching bug
2021-11-03clean/smudge: allow clean filters to process extremely large filesMatt Cooper1-0/+11
The filter system allows for alterations to file contents when they're moved between the database and the worktree. We already made sure that it is possible for smudge filters to produce contents that are larger than `unsigned long` can represent (which matters on systems where `unsigned long` is narrower than `size_t`, most notably 64-bit Windows). Now we make sure that clean filters can _consume_ contents that are larger than that. Note that this commit only allows clean filters' _input_ to be larger than can be represented by `unsigned long`. This change makes only a very minute dent into the much larger project to teach Git to use `size_t` instead of `unsigned long` wherever appropriate. Helped-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Matt Cooper <vtbassmatt@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-03odb: teach read_blob_entry to use size_tMatt Cooper1-1/+1
There is mixed use of size_t and unsigned long to deal with sizes in the codebase. Recall that Windows defines unsigned long as 32 bits even on 64-bit platforms, meaning that converting size_t to unsigned long narrows the range. This mostly doesn't cause a problem since Git rarely deals with files larger than 2^32 bytes. But adjunct systems such as Git LFS, which use smudge/clean filters to keep huge files out of the repository, may have huge file contents passed through some of the functions in entry.c and convert.c. On Windows, this results in a truncated file being written to the workdir. I traced this to one specific use of unsigned long in write_entry (and a similar instance in write_pc_item_to_fd for parallel checkout). That appeared to be for the call to read_blob_entry, which expects a pointer to unsigned long. By altering the signature of read_blob_entry to expect a size_t, write_entry can be switched to use size_t internally (which all of its callers and most of its callees already used). To avoid touching dozens of additional files, read_blob_entry uses a local unsigned long to call a chain of functions which aren't prepared to accept size_t. Helped-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Matt Cooper <vtbassmatt@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-03t1051: introduce a smudge filter test for extremely large filesMatt Cooper1-0/+15
The filter system allows for alterations to file contents when they're added to the database or working tree. ("Smudge" when moving to the working tree; "clean" when moving to the database.) This is used natively to handle CRLF to LF conversions. It's also employed by Git-LFS to replace large files from the working tree with small tracking files in the repo and vice versa. Git reads the entire smudged file into memory to convert it into a "clean" form to be used in-core. While this is inefficient, there's a more insidious problem on some platforms due to inconsistency between using unsigned long and size_t for the same type of data (size of a file in bytes). On most 64-bit platforms, unsigned long is 64 bits, and size_t is typedef'd to unsigned long. On Windows, however, unsigned long is only 32 bits (and therefore on 64-bit Windows, size_t is typedef'd to unsigned long long in order to be 64 bits). Practically speaking, this means 64-bit Windows users of Git-LFS can't handle files larger than 2^32 bytes. Other 64-bit platforms don't suffer this limitation. This commit introduces a test exposing the issue; future commits make it pass. The test simulates the way Git-LFS works by having a tiny file checked into the repository and expanding it to a huge file on checkout. Helped-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Matt Cooper <vtbassmatt@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-03test-lib: add prerequisite for 64-bit platformsCarlo Marcelo Arenas Belón1-0/+4
Allow tests that assume a 64-bit `size_t` to be skipped in 32-bit platforms and regardless of the size of `long`. This imitates the `LONG_IS_64BIT` prerequisite. Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-03test-tool genzeros: generate large amounts of data more efficientlyJohannes Schindelin1-2/+15
In this developer's tests, producing one gigabyte worth of NULs in a busy loop that writes out individual bytes, unbuffered, took ~27sec. Writing chunked 256kB buffers instead only took ~0.6sec This matters because we are about to introduce a pair of test cases that want to be able to produce 5GB of NULs, and we cannot use `/dev/zero` because of the HP NonStop platform's lack of support for that device. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-03test-genzeros: allow more than 2G zeros in WindowsCarlo Marcelo Arenas Belón1-2/+2
d5cfd142ec (tests: teach the test-tool to generate NUL bytes and use it, 2019-02-14), add a way to generate zeroes in a portable way without using /dev/zero (needed by HP NonStop), but uses a long variable that is limited to 2^31 in Windows. Use instead a (POSIX/C99) intmax_t that is at least 64bit wide in 64-bit Windows to use in a future test. Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-03rebase -i: fix rewording with --committer-date-is-author-datePhillip 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 bugDerrick 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'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'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'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'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'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'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'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'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'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'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"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"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-dateJunio 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 includeJeff 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 hookAlex 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-28send-email: programmatically generate bash completionsThiago Perrotta1-0/+3
"git send-email --git-completion-helper" only prints "format-patch" flags. Make it print "send-email" flags as well, extracting them programmatically from its three existing "GetOptions". Introduce a "uniq" subroutine, otherwise --cc-cover, --to-cover and other flags would show up twice. In addition, deduplicate flags common to both "send-email" and "format-patch", like --from. Remove extraneous flags: --h and --git-completion-helper. Add trailing "=" to options that expect an argument, inline with the format-patch implementation. Add a completion test for "send-email --validate", a send-email flag. Signed-off-by: Thiago Perrotta <tbperrotta@gmail.com> Based-on-patch-by: Ævar Arnfjörð Bjarmason <avarab@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 dirsMatheus 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-27t/helper/test-read-midx.c: free MIDX within read_midx_file()Taylor Blau1-1/+2
When calling `read_midx_file()` to show information about a MIDX or list the objects contained within it we fail to call `close_midx()`, leaking the memory allocated to store that MIDX. Fix this by calling `close_midx()` before exiting the function. We can drop the "early" return when `show_objects` is non-zero, since the next instruction is also a return. (We could just as easily put a `cleanup` label here as with previous patches. But the only other time we terminate the function early is when we fail to load a MIDX in the first place. `close_midx()` does handle a NULL argument, but the extra complexity is likely not warranted). Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-25Merge branch 'ab/test-lib-diff-cleanup'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'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'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'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'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'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'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'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'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'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'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'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'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'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'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'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 numbersJohannes 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 leakÆ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>
2021-10-21status: print stash info with --porcelain=v2 --show-stashØystein Walle1-0/+15
The v2 porcelain format is very convenient for obtaining a lot of information about the current state of the repo, but does not contain any info about the stash. git status already accepts --show-stash but it's silently ignored when --porcelain=v2 is given. Let's add a simple line to print the number of stash entries but in a format similar in style to the rest of the format. Signed-off-by: Øystein Walle <oystwa@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-21config.c: don't leak memory in handle_path_include()Ævar Arnfjörð Bjarmason1-0/+1
Fix a memory leak in the error() path in handle_path_include(), this allows us to run t1305-config-include.sh under SANITIZE=leak, previously 4 tests there would fail. This fixes up a leak in 9b25a0b52e0 (config: add include directive, 2012-02-06). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-20for-each-ref: delay parsing of --sort=<atom> optionsJunio C Hamano2-1/+37
The for-each-ref family of commands invoke parsers immediately when it sees each --sort=<atom> option, and die before even seeing the other options on the command line when the <atom> is unrecognised. Instead, accumulate them in a string list, and have them parsed into a ref_sorting structure after the command line parsing is done. As a consequence, "git branch --sort=bogus -h" used to fail to give the brief help, which arguably may have been a feature, now does so, which is more consistent with how other options work. The patch is smaller than the actual extent of the "damage" to the codebase, thanks to the fact that the original code consistently used OPT_REF_SORT() macro to handle command line options. We only needed to replace the variable used for the list, and implementation of the callback function used in the macro. The old rule was for the users of the API to: - Declare ref_sorting and ref_sorting_tail variables; - OPT_REF_SORT() macro will instantiate ref_sorting instance (which may barf and die) and append it to the tail; - Append to the tail each ref_sorting read from the configuration by parsing in the config callback (which may barf and die); - See if ref_sorting is null and use ref_sorting_default() instead. Now the rule is not all that different but is simpler: - Declare ref_sorting_options string list. - OPT_REF_SORT() macro will append it to the string list; - Append to the string list the sort key read from the configuration; - call ref_sorting_options() to turn the string list to ref_sorting structure (which also deals with the default value). As side effects, this change also cleans up a few issues: - 95be717c (parse_opt_ref_sorting: always use with NONEG flag, 2019-03-20) muses that "git for-each-ref --no-sort" should simply clear the sort keys accumulated so far; it now does. - The implementation detail of "struct ref_sorting" and the helper function parse_ref_sorting() can now be private to the ref-filter API implementation. - If you set branch.sort to a bogus value, the any "git branch" invocation, not only the listing mode, would abort with the original code; now it doesn't Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-18Merge branch 'rs/make-verify-path-really-verify-again'Junio C Hamano1-0/+6
Recent sparse-index work broke safety against attempts to add paths with trailing slashes to the index, which has been corrected. * rs/make-verify-path-really-verify-again: read-cache: let verify_path() reject trailing dir separators again read-cache: add verify_path_internal() t3905: show failure to ignore sub-repo
2021-10-18Merge branch 'jk/cat-file-batch-all-wo-replace'Junio C Hamano1-0/+75
"git cat-file --batch" with the "--batch-all-objects" option is supposed to iterate over all the objects found in a repository, but it used to translate these object names using the replace mechanism, which defeats the point of enumerating all objects in the repository. This has been corrected. * jk/cat-file-batch-all-wo-replace: cat-file: use packed_object_info() for --batch-all-objects cat-file: split ordered/unordered batch-all-objects callbacks cat-file: disable refs/replace with --batch-all-objects cat-file: mention --unordered along with --batch-all-objects t1006: clean up broken objects
2021-10-18Merge branch 'tb/repack-write-midx'Junio C Hamano6-2/+294
"git repack" has been taught to generate multi-pack reachability bitmaps. * tb/repack-write-midx: test-read-midx: fix leak of bitmap_index struct builtin/repack.c: pass `--refs-snapshot` when writing bitmaps builtin/repack.c: make largest pack preferred builtin/repack.c: support writing a MIDX while repacking builtin/repack.c: extract showing progress to a variable builtin/repack.c: rename variables that deal with non-kept packs builtin/repack.c: keep track of existing packs unconditionally midx: preliminary support for `--refs-snapshot` builtin/multi-pack-index.c: support `--stdin-packs` mode midx: expose `write_midx_file_only()` publicly
2021-10-18Merge branch 'js/retire-preserve-merges'Junio C Hamano16-766/+6
The "--preserve-merges" option of "git rebase" has been removed. * js/retire-preserve-merges: sequencer: restrict scope of a formerly public function rebase: remove a no-longer-used function rebase: stop mentioning the -p option in comments rebase: remove obsolete code comment rebase: drop the internal `rebase--interactive` command git-svn: drop support for `--preserve-merges` rebase: drop support for `--preserve-merges` pull: remove support for `--rebase=preserve` tests: stop testing `git rebase --preserve-merges` remote: warn about unhandled branch.<name>.rebase values t5520: do not use `pull.rebase=preserve`
2021-10-18Merge branch 'rs/mergesort'Junio C Hamano3-12/+407
The mergesort implementation used to sort linked list has been optimized. * rs/mergesort: test-mergesort: use repeatable random numbers mergesort: use ranks stack p0071: test performance of llist_mergesort() p0071: measure sorting of already sorted and reversed files test-mergesort: add unriffle_skewed mode test-mergesort: add unriffle mode test-mergesort: add generate subcommand test-mergesort: add test subcommand test-mergesort: add sort subcommand test-mergesort: use strbuf_getline()
2021-10-18transport-helper: recognize "expecting report" error from send-packJeff King1-1/+1
When a transport helper pushes via send-pack, it passes --helper-status to get a machine-readable status back for each ref. The previous commit taught the send-pack code to hand back "error expecting report" if the server did not send us the proper ref-status. And that's enough to cause us to recognize that an error occurred for the ref and print something sensible in our final status table. But we do interpret these messages on the remote-helper side to turn them back into REF_STATUS_* enum values. Recognizing this token to turn it back into REF_STATUS_EXPECTING_REPORT has two advantages: 1. We now print exactly the same message in the human-readable (and machine-readable --porcelain) output for this situation whether the transport went through a helper (e.g., http) or not (e.g., ssh). 2. If any code in the helper really cares about distinguishing EXPECT_REPORT from more generic error conditions, it could now do so. I didn't find any, so this is mostly future-proofing. So this is mostly cosmetic for now, but it seems like the least-surprising thing for the transport-helper code to be doing. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-18send-pack: complain about "expecting report" with --helper-statusJeff King4-0/+27
When pushing to a server which erroneously omits the final ref-status report, the client side should complain about the refs for which we didn't receive the status (because we can't just assume they were updated). This works over most transports like ssh, but for http we'll print a very misleading "Everything up-to-date". It works for ssh because send-pack internally sets the status of each ref to REF_STATUS_EXPECTING_REPORT, and then if the server doesn't tell us about a particular ref, it will stay at that value. When we print the final status table, we'll see that we're still on EXPECTING_REPORT and complain then. But for http, we go through remote-curl, which invokes send-pack with "--stateless-rpc --helper-status". The latter option causes send-pack to return a machine-readable list of ref statuses to the remote helper. But ever since its inception in de1a2fdd38 (Smart push over HTTP: client side, 2009-10-30), the send-pack code has simply omitted mention of any ref which ended up in EXPECTING_REPORT. In the remote helper, we then take the absence of any status report from send-pack to mean that the ref was not even something we tried to send, and thus it prints "Everything up-to-date". Fortunately it does detect the eventual non-zero exit from send-pack, and propagates that in its own non-zero exit code. So at least a careful script invoking "git push" would notice the failure. But sending the misleading message on stderr is certainly confusing for humans (not to mention the machine-readable "push --porcelain" output, though again, any careful script should be checking the exit code from push, too). Nobody seems to have noticed because the server in this instance has to be misbehaving: it has promised to support the ref-status capability (otherwise the client will not set EXPECTING_REPORT at all), but didn't send us any. If the connection were simply cut, then send-pack would complain about getting EOF while trying to read the status. But if the server actually sends a flush packet (i.e., saying "now you have all of the ref statuses" without actually sending any), then the client ends up in this confused situation. The fix is simple: we should return an error message from "send-pack --helper-status", just like we would for any other error per-ref error condition (in the test I included, the server simply omits all ref status responses, but a more insidious version of this would skip only some of them). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-18stash: implement '--staged' option for 'push' and 'save'Sergey Organov1-0/+11
Stash only the changes that are staged. This mode allows to easily stash-out for later reuse some changes unrelated to the current work in progress. Unlike 'stash push --patch', --staged supports use of any tool to select the changes to stash-out, including, but not limited to 'git add --interactive'. Signed-off-by: Sergey Organov <sorganov@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-18t1092: run "rebase --apply" without "-q" in testingPhillip Wood1-1/+1
We run a few operations and make sure they produce identical results with and without sparse-index; the version we merged to the "next" branch used the "-q" option to work around a breakage caused by a version used at Microsoft with some unreleased changes, but since we would want to make sure the commands produce identical results, including reports given to the output that lists which commits were picked, use of "-q" loses too much interesting information. Let's drop "-q" from the command invocation and revisit the issue when the problematic changes are upstreamed. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Helped-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-16refs API: post-migration API renaming [2/2]Ævar Arnfjörð Bjarmason1-1/+1
Rename the transitory refs_werrres_ref_unsafe() function to refs_resolve_ref_unsafe(), now that all callers of the old function have learned to pass in a "failure_errno" parameter. The coccinelle semantic patch added in the preceding commit works, but I couldn't figure out how to get spatch(1) to re-flow these argument lists (and sometimes make lines way too long), so this rename was done with: perl -pi -e 's/refs_werrres_ref_unsafe/refs_resolve_ref_unsafe/g' \ $(git grep -l refs_werrres_ref_unsafe -- '*.c') But after that "make contrib/coccinelle/refs.cocci.patch" comes up empty, so the result would have been the same. Let's remove that transitory semantic patch file, we won't need to retain it for any other in-flight changes, refs_werrres_ref_unsafe() only existed within this patch series. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-16refs tests: ignore ignore errno in test-ref-store helperÆvar Arnfjörð Bjarmason1-2/+3
The cmd_resolve_ref() function has always ignored errno on failure, but let's do so explicitly when using the refs_resolve_ref_unsafe() function. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-16reflog tests: add --updateref testsÆvar Arnfjörð Bjarmason1-0/+65
Add tests that cover blindspots in "git reflog delete --updateref" behavior. Before this change removing the "type & REF_ISSYMREF" check added in 5e6f003ca8a (reflog_expire(): ignore --updateref for symbolic references, 2015-03-03) would not fail any tests. The "--updateref" option was added in 55f10565371 (git-reflog: add option --updateref to write the last reflog sha1 into the ref, 2008-02-22) for use in git-stash.sh, see e25d5f9c82e (git-stash: add new 'drop' subcommand, 2008-02-22). Even though the regression test I need is just the "C" case here, let's test all these combinations for good measure. I started out doing these as a for-loop, but I think this is more readable. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-16branch tests: test for errno propagating on failing readHan-Wen Nienhuys1-0/+22
Add a test for "git branch" to cover the case where .git/refs is symlinked. To check availability, refs_verify_refname_available() will run refs_read_raw_ref() on each prefix, leading to a read() from .git/refs (which is a directory). It would probably be more robust to re-issue the lstat() as a normal stat(), in which case, we would fall back to the directory case, but for now let's just test for the existing behavior as-is. This test covers a regression in a commit that only ever made it to "next", see [1]. 1. http://lore.kernel.org/git/pull.1068.git.git.1629203489546.gitgitgadget@gmail.com Signed-off-by: Han-Wen Nienhuys <hanwen@google.com> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-15gc: perform incremental repack when implictly enabledGlen Choo1-4/+24
builtin/gc.c has two ways of checking if multi-pack-index is enabled: - git_config_get_bool() in incremental_repack_auto_condition() - the_repository->settings.core_multi_pack_index in maintenance_task_incremental_repack() The two implementations have existed since the incremental-repack task was introduced in e841a79a13 (maintenance: add incremental-repack auto condition, 2020-09-25). These two values can diverge because prepare_repo_settings() enables the feature in the_repository->settings by default. In the case where core.multiPackIndex is not set in the config, the auto condition would fail, causing the incremental-repack task to not be run. Because we always want to consider the default values, we should always use the_repository->settings. Standardize on using the_repository->settings.core_multi_pack_index to check if multi-pack-index is enabled. Signed-off-by: Glen Choo <chooglen@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-15fsck: verify multi-pack-index when implictly enabledGlen Choo1-1/+4
Like the previous commit, change fsck to check the "core_multi_pack_index" variable set in "repo-settings.c" instead of reading the "core.multiPackIndex" config variable. This fixes a bug where we wouldn't verify midx if the config key was missing. This bug was introduced in 18e449f86b (midx: enable core.multiPackIndex by default, 2020-09-25) where core.multiPackIndex was turned on by default. Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Glen Choo <chooglen@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-15fsck: verify commit graph when implicitly enabledGlen Choo2-2/+27
Change fsck to check the "core_commit_graph" variable set in "repo-settings.c" instead of reading the "core.commitGraph" variable. This fixes a bug where we wouldn't verify the commit-graph if the config key was missing. This bug was introduced in 31b1de6a09 (commit-graph: turn on commit-graph by default, 2019-08-13), where core.commitGraph was turned on by default. Add tests to "t5318-commit-graph.sh" to verify that fsck checks the commit-graph as expected for the 3 values of core.commitGraph. Also, disable GIT_TEST_COMMIT_GRAPH in t/t0410-partial-clone.sh because some test cases use fsck in ways that assume that commit-graph checking is disabled. Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Glen Choo <chooglen@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-15Merge branch 'ab/ignore-replace-while-working-on-commit-graph' into ↵Junio C Hamano2-10/+15
gc/use-repo-settings * 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-10-15grep/pcre2: fix an edge case concerning ascii patterns and UTF-8 dataHamza Mahfooz1-0/+48
If we attempt to grep non-ascii log message text with an ascii pattern, we run into the following issue: $ git log --color --author='.var.*Bjar' -1 origin/master | grep ^Author grep: (standard input): binary file matches So, to fix this teach the grep code to use PCRE2_UTF, as long as the log output is encoded in UTF-8. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Hamza Mahfooz <someguy@effective-light.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-15tests: stop using top-level "README" and "COPYING" filesÆvar Arnfjörð Bjarmason4-14/+19
In 459b8d22e54 (tests: do not borrow from COPYING and README from the real source, 2015-02-15) tests that used "lib-diff.sh" (called "diff-lib.sh" then) were made to stop relying on the top-level COPYING file, but we still had other tests that referenced it. Let's move them over to use the "COPYING_test_data" utility function introduced in the preceding commit, and in the case of the one test that needed the "README" file use a ROT 13 version of that "COPYING" test data. That test added in afd222967c6 (Extend testing git-mv for renaming of subdirectories, 2006-07-26) just needs more test data that's not the same as the "COPYING" test data, so a ROT 13 version will do. This change removes the last references to ../{README,COPYING} in the test suite. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-15"lib-diff" tests: make "README" and "COPYING" test data smallerÆvar Arnfjörð Bjarmason10-419/+34
Follow-up the change in 459b8d22e54 (tests: do not borrow from COPYING and README from the real source, 2015-02-15) by not shipping a full copy of older versions of the top-level "COPYING" and "README" files. The tests that use them just need the small blurb at the top of "COPYING" as test data, or mock data that's dissimilar. Let's provide that with a "COPYING_test_data" function instead. We're not replacing this with some other generic test data (e.g. "lorum ipsum") because these tests require test file header to be the old "COPYING" file. See e.g. "t4003-diff-rename-1.sh" which changes the file, and then does full "test_cmp" comparisons on the resulting "git diff" output. This change only changes tests that used the "lib-diff.sh" library, but splits up what they need into a new "lib-diff-data.sh". A subsequent commit will change related tests that were missed in 459b8d22e54. For the test in "t4008-diff-break-rewrite.sh" the "README" file can go away in favor of echoing the line "some dissimilar content" to a file in the one test that needed it. The point of that test is to start with files "A" and "B", and then have A be more similar to the state of "B" than to its old version (by copying over the content from the "COPYING" file). Just comparing the pre-image of "some dissimilar content" and later a munged version of the "COPYING" output serves that purpose. While we're at it get rid of a stray "echo $tree" debugging line added in 15d061b435a ([PATCH] Fix the way diffcore-rename records unremoved source., 2005-05-27), and stop calling "hash-object" to get the hash of an object we've just added to the index. We can instead extract that information from the index itself with "rev-parse". Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-15commit-graph: don't consider "replace" objects with "verify"Ævar Arnfjörð Bjarmason1-0/+1
Extend the code added in d6538246d3d (commit-graph: not compatible with replace objects, 2018-08-20) which ignored replace objects in the "write" command to ignore it in the "verify" command too. We can just move this assignment to the cmd_commit_graph(), it dispatches to "write" and "verify", and we're unlikely to ever get a sub-command that would like to consider replace refs. This will make tests added in eddc1f556cd (mktag tests: test update-ref and reachable fsck, 2021-06-17) pass in combination with the "GIT_TEST_COMMIT_GRAPH" mode added in 859fdc0c3cf (commit-graph: define GIT_TEST_COMMIT_GRAPH, 2018-08-29), except that mode is currently broken (but is being fixed concurrently). See the discussion starting at [1]. 1. https://lore.kernel.org/git/87wnmihswp.fsf@evledraar.gmail.com/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-15commit-graph tests: fix another graph_git_two_modes() helperÆvar Arnfjörð Bjarmason1-8/+12
In 135a7123755 (commit-graph: add --split option to builtin, 2019-06-18) this function was copy/pasted to the split commit-graph tests, as in the preceding commit we need to fix this to use &&-chaining, so it won't be hiding errors. Unlike its sister function in "t5318-commit-graph.sh", which we got lucky with, this one was hiding a real test failure. A tests added in c523035cbd8 (commit-graph: allow cross-alternate chains, 2019-06-18) has never worked as intended. Unlike most other graph_git_behavior uses in this file it clones the repository into a sub-directory, so we'll need to refer to "commits/6" as "origin/commits/6". It's not easy to simply move the "graph_git_behavior" to the test above it, since it itself spawns a "test_expect_success". Let's instead add support to "graph_git_behavior()" and "graph_git_two_modes()" to pass a "-C" argument to git. We also need to add a "test -d fork" here, because otherwise we'll fail on e.g.: GIT_SKIP_TESTS=t5324.13 ./t5324-split-commit-graph.sh Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-15commit-graph tests: fix error-hiding graph_git_two_modes() helperÆvar Arnfjörð Bjarmason1-2/+2
The graph_git_two_modes() helper added in 177722b3442 (commit: integrate commit graph with commit parsing, 2018-04-10) didn't &&-chain its "git commit-graph" invocations, which as can be seen with SANITIZE=leak will happily mark tests as passing if both of these commands die, since test_cmp() will be comparing two empty files. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-15test-lib.sh: try to re-chmod & retry on failed trash removalÆvar Arnfjörð Bjarmason1-1/+13
Try to re-chmod the trash directory on startup if we fail to "rm -rf" it. This fixes problems where the test leaves the trash directory behind in a bad permission state for whatever reason. This fixes an interaction between [1] where t0004-unwritable.sh was made to use "test_when_finished" for cleanup, and [2] which added the "--immediate" mode. If a test in this file failed when running with "--immediate" we wouldn't run the "test_when_finished" block, which re-chmods the ".git/objects" directory (see [1]). This can be demonstrated as e.g. (output snipped for less verbosity): $ ./t0004-unwritable.sh --run=3 --immediate ok 1 # skip setup (--run) ok 2 # skip write-tree should notice unwritable repository (--run) not ok 3 - commit should notice unwritable repository [...] $ ./t0004-unwritable.sh --run=3 --immediate rm: cannot remove '[...]/trash directory.t0004-unwritable/.git/objects/info': Permission denied FATAL: Cannot prepare test area [...] Instead of some version of reverting [1] let's make the test-lib.sh resilient to this edge-case, it will happen due to [1], but also e.g. if the relevant "test-lib.sh" process is kill -9'd during the test run. We should try harder to recover in this case. If we fail to remove the test directory let's retry after (re-)chmod-ing it. This doesn't need to be guarded by something that's equivalent to "POSIXPERM" since if we don't support "chmod" we were about to fail anyway. Let's also discard any error output from (a possibly nonexisting) "chmod", we'll fail on the subsequent "rm -rf" anyway, likewise for the first "rm -rf" invocation, we don't want to get the "cannot remove" output if we can get around it with the "chmod", but we do want any error output from the second "rm -rf", in case that doesn't fix the issue. The lack of &&-chaining between the "chmod" and "rm -rf" is intentional, if we fail the first "rm -rf", can't chmod, but then succeed the second time around that's what we were hoping for. We just want to nuke the directory, not carry forward every possible error code or error message. 1. dbda967684d (t0004 (unwritable files): simplify error handling, 2010-09-06) 2. b586744a864 (test: skip clean-up when running under --immediate mode, 2011-06-27) Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-14test-lib.sh: use "Bail out!" syntax on bad SANITIZE=leak useÆvar Arnfjörð Bjarmason1-4/+14
Improve the "GIT_TEST_PASSING_SANITIZE_LEAK=true" test mode added in 956d2e4639b (tests: add a test mode for SANITIZE=leak, run it in CI, 2021-09-23) to use a TAP "Bail out!" message when exiting. This will cause the test run to exit immediately under a TAP consumer like "prove(1)". See 614fe015212 (test-lib: bail out when "-v" used under "prove", 2016-10-22) for the initial introduction of "Bail out!" to the --verbose being amended here. Before this compiling with "SANITIZE=" and running the tests with "prove(1)" would cause all the tests to be run to the end (output trimmed for fewer columns): $ GIT_TEST_PASSING_SANITIZE_LEAK=true make rm -f -r 'test-results' *** prove *** t0000-basic.sh ......... Dubious, test returned 1 (wstat 256, 0x100) No subtests run t0001-init.sh .......... Dubious, test returned 1 (wstat 256, 0x100) No subtests run [...output where we list every single t[0-9]*.sh file as failing snipped] Whereas now we'll fail early, like this ("->" line wrapping added): $ GIT_TEST_PASSING_SANITIZE_LEAK=true make [...] t0000-basic.sh ..................................... Bailout called. Further testing stopped: -> GIT_TEST_PASSING_SANITIZE_LEAK=true has no effect except when compiled with SANITIZE=leak FAILED--Further testing stopped: GIT_TEST_PASSING_SANITIZE_LEAK=true has no effect except -> when compiled with SANITIZE=leak make: *** [Makefile:53: prove] Error 1 This change also adds a red color to the "Bailout called" line, as we're now using "say_color error". That improves existing output in the case of e.g.: $ prove -j8 t[0-9]*.sh :: -v Bailout called. Further testing stopped: verbose mode forbidden under TAP harness; try --verbose-log FAILED--Further testing stopped: verbose mode forbidden under TAP harness; try --verbose-log We don't need to have a "Bail out! " prefix when we're not running under a TAP consumer (i.e. if test -n "$HARNESS_ACTIVE"), but let's not make the output conditional on that. Showing it under e.g.: $ GIT_TEST_PASSING_SANITIZE_LEAK=true ./t0095-bloom.sh Bail out! GIT_TEST_PASSING_SANITIZE_LEAK=true has no effect except when compiled with SANITIZE=leak Doesn't harm anything, and I don't think the (small) complexity of only adding this if we're under "$HARNESS_ACTIVE" is worth it. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-14test-lib.sh: de-duplicate error() teardown codeÆvar Arnfjörð Bjarmason1-3/+7
De-duplicate the "finalize_junit_xml; GIT_EXIT_OK=t; exit 1" code shared between the "error()" and "--immediate on failure" code paths, in preparation for adding a third user in a subsequent commit. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-13Merge branch 'ab/align-parse-options-help'Junio C Hamano1-0/+54
When "git cmd -h" shows more than one line of usage text (e.g. the cmd subcommand may take sub-sub-command), parse-options API learned to align these lines, even across i18n/l10n. * ab/align-parse-options-help: parse-options: properly align continued usage output git rev-parse --parseopt tests: add more usagestr tests send-pack: properly use parse_options() API for usage string parse-options API users: align usage output in C-strings
2021-10-13Merge branch 'ab/help-config-vars'Junio C Hamano1-0/+49
Teach "git help -c" into helping the command line completion of configuration variables. * ab/help-config-vars: help: move column config discovery to help.c library help / completion: make "git help" do the hard work help tests: test --config-for-completion option & output help: simplify by moving to OPT_CMDMODE() help: correct logic error in combining --all and --guides help: correct logic error in combining --all and --config help tests: add test for --config output help: correct usage & behavior of "git help --guides" help: correct the usage string in -h and documentation
2021-10-13Merge branch 'jh/builtin-fsmonitor-part1'Junio C Hamano1-167/+66
Built-in fsmonitor (part 1). * jh/builtin-fsmonitor-part1: t/helper/simple-ipc: convert test-simple-ipc to use start_bg_command run-command: create start_bg_command simple-ipc/ipc-win32: add Windows ACL to named pipe simple-ipc/ipc-win32: add trace2 debugging simple-ipc: move definition of ipc_active_state outside of ifdef simple-ipc: preparations for supporting binary messages. trace2: add trace2_child_ready() to report on background children
2021-10-13Merge branch 'ab/lib-subtest'Junio C Hamano2-330/+213
Updates to the tests in t0000 to test the test framework. * ab/lib-subtest: test-lib tests: get rid of copy/pasted mock test code test-lib tests: assert 1 exit code, not non-zero test-lib tests: refactor common part of check_sub_test_lib_test*() test-lib tests: avoid subshell for "test_cmp" for readability test-lib tests: don't provide a description for the sub-tests test-lib tests: split up "write and run" into two functions test-lib tests: move "run_sub_test" to a new lib-subtest.sh
2021-10-13Merge branch 'en/removing-untracked-fixes'Junio C Hamano3-2/+244
Various fixes in code paths that move untracked files away to make room. * en/removing-untracked-fixes: Documentation: call out commands that nuke untracked files/directories Comment important codepaths regarding nuking untracked files/dirs unpack-trees: avoid nuking untracked dir in way of locally deleted file unpack-trees: avoid nuking untracked dir in way of unmerged file Change unpack_trees' 'reset' flag into an enum Remove ignored files by default when they are in the way unpack-trees: make dir an internal-only struct unpack-trees: introduce preserve_ignored to unpack_trees_options read-tree, merge-recursive: overwrite ignored files by default checkout, read-tree: fix leak of unpack_trees_options.dir t2500: add various tests for nuking untracked files
2021-10-13Merge branch 'mt/grep-submodule-textconv'Junio C Hamano1-0/+103
"git grep --recurse-submodules" takes trees and blobs from the submodule repository, but the textconv settings when processing a blob from the submodule is not taken from the submodule repository. A test is added to demonstrate the issue, without fixing it. * mt/grep-submodule-textconv: grep: demonstrate bug with textconv attributes and submodules
2021-10-13Merge branch 'ds/add-rm-with-sparse-index'Junio C Hamano5-24/+352
"git add", "git mv", and "git rm" have been adjusted to avoid updating paths outside of the sparse-checkout definition unless the user specifies a "--sparse" option. * ds/add-rm-with-sparse-index: advice: update message to suggest '--sparse' mv: refuse to move sparse paths rm: skip sparse paths with missing SKIP_WORKTREE rm: add --sparse option add: update --renormalize to skip sparse paths add: update --chmod to skip sparse paths add: implement the --sparse option add: skip tracked paths outside sparse-checkout cone add: fail when adding an untracked sparse file dir: fix pattern matching on dirs dir: select directories correctly t1092: behavior for adding sparse files t3705: test that 'sparse_entry' is unstaged
2021-10-12urlmatch: add underscore to URL_HOST_CHARSJeff King1-1/+1
When parsing a URL to normalize it, we allow hostnames to contain only dot (".") or dash ("-"), plus brackets and colons for IPv6 literals. This matches the old URL standard in RFC 1738, which says: host = hostname | hostnumber hostname = *[ domainlabel "." ] toplabel domainlabel = alphadigit | alphadigit *[ alphadigit | "-" ] alphadigit But this was later updated by RFC 3986, which is more liberal: host = IP-literal / IPv4address / reg-name reg-name = *( unreserved / pct-encoded / sub-delims ) unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" While names with underscore in them are not common and possibly violate some DNS rules, they do work in practice, and we will happily contact them over http://, git://, or ssh://. It seems odd to ignore them for purposes of URL matching, especially when the URL RFC seems to allow them. There shouldn't be any downside here. It's not a syntactically significant character in a URL, so we won't be confused about parsing; we'd have simply rejected such a URL previously (the test here checks the url code directly, but the obvious user-visible effect would be failing to match credential.http://foo_bar.example.com.helper, or similar config in http.<url>.*). Arguably we'd want to allow tilde ("~") here, too. There's likewise probably no downside, but I didn't add it simply because it seems like an even less likely character to appear in a hostname. Reported-by: Alex Waite <alex@waite.eu> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-12leak tests: mark some misc tests as passing with SANITIZE=leakÆvar Arnfjörð Bjarmason10-0/+12
Mark some tests that match "*{mktree,commit,diff,grep,rm,merge,hunk}*" as passing when git is compiled with SANITIZE=leak. They'll now be listed as running under the "GIT_TEST_PASSING_SANITIZE_LEAK=true" test mode (the "linux-leaks" CI target). These were picked because we still have a lot of failures in adjacent areas, and we didn't have much if any coverage of e.g. grep and diff before this change, we could still whitelist a lot more tests, but let's stop for now. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-12leak tests: mark various "generic" tests as passing with SANITIZE=leakÆvar Arnfjörð Bjarmason14-0/+18
Mark various "generic" tests as passing when git is compiled with SANITIZE=leak. These tests were subjectively picked from the lists of passing tests since they're all small, and test some generic feature such as wildmatch(), commonly used environment variables, ident parsing etc. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-12leak tests: mark some read-tree tests as passing with SANITIZE=leakÆvar Arnfjörð Bjarmason5-0/+7
Mark some tests that match "*read-tree*" as passing when git is compiled with SANITIZE=leak. They'll now be listed as running under the "GIT_TEST_PASSING_SANITIZE_LEAK=true" test mode (the "linux-leaks" CI target). We still have around half the tests that match "*read-tree*" failing, but let's whitelist those that don't. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-12leak tests: mark some ls-files tests as passing with SANITIZE=leakÆvar Arnfjörð Bjarmason6-0/+10
Mark some tests that match "*ls-files*" as passing when git is compiled with SANITIZE=leak. They'll now be listed as running under the "GIT_TEST_PASSING_SANITIZE_LEAK=true" test mode (the "linux-leaks" CI target). We still have others that match '*ls-files*" that fail under SANITIZE=leak. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-12leak tests: mark all checkout-index tests as passing with SANITIZE=leakÆvar Arnfjörð Bjarmason5-0/+5
Mark some tests that match "*{checkout,switch}*" as passing when git is compiled with SANITIZE=leak. They'll now be listed as running under the "GIT_TEST_PASSING_SANITIZE_LEAK=true" test mode (the "linux-leaks" CI target). Unfortunately almost all of those tests fail when compiled with SANITIZE=leak, these only pass because they run "checkout-index", not the main "checkout" command. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-12leak tests: mark all trace2 tests as passing with SANITIZE=leakÆvar Arnfjörð Bjarmason3-0/+6
Mark all tests that match "*trace2*" as passing when git is compiled with SANITIZE=leak. They'll now be listed as running under the "GIT_TEST_PASSING_SANITIZE_LEAK=true" test mode (the "linux-leaks" CI target). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-12leak tests: mark all ls-tree tests as passing with SANITIZE=leakÆvar Arnfjörð Bjarmason4-0/+6
Mark those tests that match "*ls-tree*" as passing when git is compiled with SANITIZE=leak. They'll now be listed as running under the "GIT_TEST_PASSING_SANITIZE_LEAK=true" test mode (the "linux-leaks" CI target). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-12leak tests: run various "test-tool" tests in t00*.sh SANITIZE=leakÆvar Arnfjörð Bjarmason6-0/+7
Mark various existing tests in t00*.sh that invoke a "test-tool" with as passing when git is compiled with SANITIZE=leak. They'll now be listed as running under the "GIT_TEST_PASSING_SANITIZE_LEAK=true" test mode (the "linux-leaks" CI target). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-12leak tests: run various built-in tests in t00*.sh SANITIZE=leakÆvar Arnfjörð Bjarmason13-0/+15
Mark various existing tests in t00*.sh that invoke git built-ins with TEST_PASSES_SANITIZE_LEAK=true as passing when git is compiled with SANITIZE=leak. They'll now be listed as running under the "GIT_TEST_PASSING_SANITIZE_LEAK=true" test mode (the "linux-leaks" CI target). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-12Merge branch 'ah/connect-parse-feature-v0-fix' into maintJunio C Hamano1-0/+15
Protocol v0 clients can get stuck parsing a malformed feature line. * ah/connect-parse-feature-v0-fix: connect: also update offset for features without values
2021-10-12Merge branch 'jk/http-redact-fix' into maintJunio C Hamano1-12/+12
Sensitive data in the HTTP trace were supposed to be redacted, but we failed to do so in HTTP/2 requests. * jk/http-redact-fix: http: match headers case-insensitively when redacting
2021-10-12Merge branch 'da/difftool-dir-diff-symlink-fix' into maintJunio C Hamano1-2/+65
"git difftool --dir-diff" mishandled symbolic links. * da/difftool-dir-diff-symlink-fix: difftool: fix symlink-file writing in dir-diff mode
2021-10-12Merge branch 'cb/cvsserver' into maintJunio C Hamano1-1/+8
"git cvsserver" had a long-standing bug in its authentication code, which has finally been corrected (it is unclear and is a separate question if anybody is seriously using it, though). * cb/cvsserver: Documentation: cleanup git-cvsserver git-cvsserver: protect against NULL in crypt(3) git-cvsserver: use crypt correctly to compare password hashes
2021-10-12Merge branch 'jk/clone-unborn-head-in-bare' into maintJunio C Hamano1-0/+13
"git clone" from a repository whose HEAD is unborn into a bare repository didn't follow the branch name the other side used, which is corrected. * jk/clone-unborn-head-in-bare: clone: handle unborn branch in bare repos
2021-10-12Merge branch 'en/stash-df-fix' into maintJunio C Hamano1-0/+58
"git stash", where the tentative change involves changing a directory to a file (or vice versa), was confused, which has been corrected. * en/stash-df-fix: stash: restore untracked files AFTER restoring tracked files stash: avoid feeding directories to update-index t3903: document a pair of directory/file bugs
2021-10-12Merge branch 'en/am-abort-fix' into maintJunio C Hamano1-0/+39
When "git am --abort" fails to abort correctly, it still exited with exit status of 0, which has been corrected. * en/am-abort-fix: am: fix incorrect exit status on am fail to abort t4151: add a few am --abort tests git-am.txt: clarify --abort behavior
2021-10-12Merge branch 'ps/update-ref-batch-flush' into maintJunio C Hamano1-0/+34
"git update-ref --stdin" failed to flush its output as needed, which potentially led the conversation to a deadlock. * ps/update-ref-batch-flush: t1400: avoid SIGPIPE race condition on fifo update-ref: fix streaming of status updates
2021-10-12Merge branch 'jc/trivial-threeway-binary-merge' into maintJunio C Hamano1-0/+45
The "git apply -3" code path learned not to bother the lower level merge machinery when the three-way merge can be trivially resolved without the content level merge. * jc/trivial-threeway-binary-merge: apply: resolve trivial merge without hitting ll-merge with "--3way"
2021-10-12Merge branch 'ab/send-email-config-fix' into maintJunio C Hamano1-0/+15
Regression fix. * ab/send-email-config-fix: send-email: fix a "first config key wins" regression in v2.33.0
2021-10-12Merge branch 'jk/log-warn-on-bogus-encoding' into maintJunio C Hamano1-0/+7
Doc update plus improved error reporting. * jk/log-warn-on-bogus-encoding: docs: use "character encoding" to refer to commit-object encoding logmsg_reencode(): warn when iconv() fails
2021-10-12Merge branch 'tk/fast-export-anonymized-tag-fix' into maintJunio C Hamano1-4/+6
The output from "git fast-export", when its anonymization feature is in use, showed an annotated tag incorrectly. * tk/fast-export-anonymized-tag-fix: fast-export: fix anonymized tag using original length
2021-10-12Merge branch 'mh/send-email-reset-in-reply-to' into maintJunio C Hamano1-0/+45
Even when running "git send-email" without its own threaded discussion support, a threading related header in one message is carried over to the subsequent message to result in an unwanted threading, which has been corrected. * mh/send-email-reset-in-reply-to: send-email: avoid incorrect header propagation
2021-10-12Merge branch 'sg/set-ceiling-during-tests' into maintJunio C Hamano1-1/+2
Buggy tests could damage repositories outside the throw-away test area we created. We now by default export GIT_CEILING_DIRECTORIES to limit the damage from such a stray test. * sg/set-ceiling-during-tests: test-lib: set GIT_CEILING_DIRECTORIES to protect the surrounding repository
2021-10-12Merge branch 'ka/want-ref-in-namespace' into maintJunio C Hamano1-36/+172
"git upload-pack" which runs on the other side of "git fetch" forgot to take the ref namespaces into account when handling want-ref requests. * ka/want-ref-in-namespace: docs: clarify the interaction of transfer.hideRefs and namespaces upload-pack.c: treat want-ref relative to namespace t5730: introduce fetch command helper
2021-10-12Merge branch 'sg/column-nl' into maintJunio C Hamano1-0/+18
The parser for the "--nl" option of "git column" has been corrected. * sg/column-nl: column: fix parsing of the '--nl' option
2021-10-12Merge branch 'rs/branch-allow-deleting-dangling' into maintJunio C Hamano1-0/+13
"git branch -D <branch>" used to refuse to remove a broken branch ref that points at a missing commit, which has been corrected. * rs/branch-allow-deleting-dangling: branch: allow deleting dangling branches with --force
2021-10-12Merge branch 'mt/quiet-with-delayed-checkout' into maintJunio C Hamano1-0/+71
The delayed checkout code path in "git checkout" etc. were chatty even when --quiet and/or --no-progress options were given. * mt/quiet-with-delayed-checkout: checkout: make delayed checkout respect --quiet and --no-progress
2021-10-12Merge branch 'dd/diff-files-unmerged-fix' into maintJunio C Hamano1-0/+53
"git diff --relative" segfaulted and/or produced incorrect result when there are unmerged paths. * dd/diff-files-unmerged-fix: diff-lib: ignore paths that are outside $cwd if --relative asked
2021-10-12Merge branch 'pw/rebase-r-fixes' into maintJunio C Hamano3-9/+98
Various bugs in "git rebase -r" have been fixed. * pw/rebase-r-fixes: rebase -r: fix merge -c with a merge strategy rebase -r: don't write .git/MERGE_MSG when fast-forwarding rebase -i: add another reword test rebase -r: make 'merge -c' behave like reword
2021-10-12Merge branch 'pw/rebase-skip-final-fix' into maintJunio C Hamano2-6/+25
Checking out all the paths from HEAD during the last conflicted step in "git rebase" and continuing would cause the step to be skipped (which is expected), but leaves MERGE_MSG file behind in $GIT_DIR and confuses the next "git commit", which has been corrected. * pw/rebase-skip-final-fix: rebase --continue: remove .git/MERGE_MSG rebase --apply: restore some tests t3403: fix commit authorship
2021-10-12Merge branch 'jk/commit-edit-fixup-fix' into maintJunio C Hamano1-1/+8
"git commit --fixup" now works with "--edit" again, after it was broken in v2.32. * jk/commit-edit-fixup-fix: commit: restore --edit when combined with --fixup
2021-10-12Merge branch 'jk/apply-binary-hunk-parsing-fix' into maintJunio C Hamano1-0/+23
"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-10-12Merge branch 'en/pull-conflicting-options' into maintJunio C Hamano11-62/+266
"git pull" had various corner cases that were not well thought out around its --rebase backend, e.g. "git pull --ff-only" did not stop but went ahead and rebased when the history on other side is not a descendant of our history. The series tries to fix them up. * en/pull-conflicting-options: pull: fix handling of multiple heads pull: update docs & code for option compatibility with rebasing pull: abort by default when fast-forwarding is not possible pull: make --rebase and --no-rebase override pull.ff=only pull: since --ff-only overrides, handle it first pull: abort if --ff-only is given and fast-forwarding is impossible t7601: add tests of interactions with multiple merge heads and config t7601: test interaction of merge/rebase/fast-forward flags and options
2021-10-12Merge branch 'jt/push-negotiation-fixes' into maintJunio C Hamano3-1/+88
Bugfix for common ancestor negotiation recently introduced in "git push" codepath. * jt/push-negotiation-fixes: fetch: die on invalid --negotiation-tip hash send-pack: fix push nego. when remote has refs send-pack: fix push.negotiate with remote helper
2021-10-12Merge branch 'ab/pack-stdin-packs-fix' into maintJunio C Hamano1-0/+104
Input validation of "git pack-objects --stdin-packs" has been corrected. * ab/pack-stdin-packs-fix: pack-objects: fix segfault in --stdin-packs option pack-objects tests: cover blindspots in stdin handling
2021-10-12Merge branch 'cb/plug-leaks-in-alloca-emu-users' into maintJunio C Hamano1-11/+12
Leakfix. * cb/plug-leaks-in-alloca-emu-users: t0000: avoid masking git exit value through pipes tree-diff: fix leak when not HAVE_ALLOCA_H
2021-10-12Merge branch 'jk/t5562-racefix' into maintJunio C Hamano1-8/+8
Test update. * jk/t5562-racefix: t5562: use alarm() to interrupt timed child-wait
2021-10-12Merge branch 'dd/t6300-wo-gpg-fix' into maintJunio C Hamano1-11/+18
Test fix. * dd/t6300-wo-gpg-fix: t6300: check for cat-file exit status code t6300: don't run cat-file on non-existent object
2021-10-12Merge branch 'jk/t5323-no-pack-test-fix' into maintJunio C Hamano1-2/+2
Test fix. * jk/t5323-no-pack-test-fix: t5323: drop mentions of "master"
2021-10-12Merge branch 'js/maintenance-launchctl-fix' into maintJunio C Hamano1-0/+17
"git maintenance" scheduler fix for macOS. * js/maintenance-launchctl-fix: maintenance: skip bootout/bootstrap when plist is registered maintenance: create `launchctl` configuration using a lock file
2021-10-12Merge branch 'ab/ls-remote-packet-trace' into maintJunio C Hamano1-3/+3
Debugging aid fix. * ab/ls-remote-packet-trace: ls-remote: set packet_trace_identity(<name>)
2021-10-12Merge branch 'ga/send-email-sendmail-cmd' into maintJunio C Hamano1-1/+1
Test fix. * ga/send-email-sendmail-cmd: t9001: PATH must not use Windows-style paths
2021-10-12Merge branch 'me/t5582-cleanup' into maintJunio C Hamano1-1/+0
Test fix. * me/t5582-cleanup: t5582: remove spurious 'cd "$D"' line
2021-10-12Merge branch 'fc/completion-updates' into maintJunio C Hamano1-0/+15
Command line completion updates. * fc/completion-updates: completion: bash: add correct suffix in variables completion: bash: fix for multiple dash commands completion: bash: fix for suboptions with value completion: bash: fix prefix detection in branch.*
2021-10-12Merge branch 'js/log-protocol-version' into maintJunio C Hamano1-0/+11
Debugging aid. * js/log-protocol-version: connect, protocol: log negotiated protocol version
2021-10-12add: don't write objects with --dry-runRené Scharfe1-0/+3
When the option --dry-run/-n is given, "git add" doesn't change the index, but still writes out new object files. Only hash the latter without writing instead to make the run as dry as possible. Use this opportunity to also make the hash_flags variable unsigned, to match the index_path() parameter it is used as. Reported-by: git.mexon@spamgourmet.com Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-12commit: fix duplication regression in permission error outputÆvar Arnfjörð Bjarmason1-1/+1
Fix a regression in the error output emitted when .git/objects can't be written to. Before 9c4d6c0297b (cache-tree: Write updated cache-tree after commit, 2014-07-13) we'd emit only one "insufficient permission" error, now we'll do so again. The cause is rather straightforward, we've got WRITE_TREE_SILENT for the use-case of wanting to prepare an index silently, quieting any permission etc. error output. Then when we attempt to update to that (possibly broken) index we'll run into the same errors again. But with 9c4d6c0297b the gap between the cache-tree API and the object store wasn't closed in terms of asking write_object_file() to be silent. I.e. post-9c4d6c0297b the first call is to prepare_index(), and after that we'll call prepare_to_commit(). We only want verbose error output from the latter. So let's add and use that facility with a corresponding HASH_SILENT flag, its only user is cache-tree.c's update_one(), which will set it if its "WRITE_TREE_SILENT" flag is set. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-12unwritable tests: assert exact error outputÆvar Arnfjörð Bjarmason1-4/+43
In preparation for fixing a regression where we started emitting some of these error messages twice, let's assert what the output from "git commit" and friends is now in the case of permission errors. As noted in [1] using test_expect_failure to mark up a TODO test has some unexpected edge cases, e.g. we don't want to break --run=3 by skipping the "test_lazy_prereq" here. This pattern allows us to test just the test_cmp (and the "cat", which shouldn't fail) with the added "test_expect_failure", we'll flip that to a "test_expect_success" in the next commit. 1. https://lore.kernel.org/git/87tuhmk19c.fsf@evledraar.gmail.com/T/#u Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-12ssh signing: fmt-merge-msg tests & config parseFabian Stelzer1-0/+28
When merging a signed tag fmt-merge-msg was unable to verify its validity missing the necessary ssh allowedSignersFile config. Adds gpg config parsing to fmt-merge-msg. Adds tests for ssh signed tags to fmt-merge-msg tests. Signed-off-by: Fabian Stelzer <fs@gigacodes.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-12Merge branch 'fs/ssh-signing' into fs/ssh-signing-fixJunio C Hamano6-1/+739
* 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-11perf: disable automatic housekeepingRené Scharfe2-0/+6
Turn off automatic background maintenance for perf tests by default to avoid interference with performance measurements. Do that by using the new file t/perf/config and using it as the system config file for perf tests. Future tests intended to measure gc performance can override the setting locally or call "git gc" explicitly. This fixes a breakage in p2000 caused by gc automatically emptying the reflog due its fake dates from 2005 being older than 90 days. Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-11Merge branch 'tb/aggregate-ignore-leading-whitespaces'Junio C Hamano1-2/+2
Test portability update. * tb/aggregate-ignore-leading-whitespaces: t/perf/aggregate.perl: tolerate leading spaces
2021-10-11Merge branch 'rs/p3400-lose-tac'Junio C Hamano1-1/+1
Test portability update. * rs/p3400-lose-tac: p3400: stop using tac(1)
2021-10-11Merge branch 'da/difftool'Junio C Hamano1-0/+7
Code clean-up in "git difftool". * da/difftool: difftool: add a missing space to the run_dir_diff() comments difftool: remove an unnecessary call to strbuf_release() difftool: refactor dir-diff to write files using helper functions difftool: create a tmpdir path without repeated slashes
2021-10-11Merge branch 'ab/designated-initializers'Junio C Hamano1-2/+4
Code clean-up. * ab/designated-initializers: cbtree.h: define cb_init() in terms of CBTREE_INIT *.h: move some *_INIT to designated initializers *.h _INIT macros: don't specify fields equal to 0 *.[ch] *_INIT macros: use { 0 } for a "zero out" idiom submodule-config.h: remove unused SUBMODULE_INIT macro
2021-10-11Merge branch 'ab/sanitize-leak-ci'Junio C Hamano10-1/+39
CI learns to run the leak sanitizer builds. * ab/sanitize-leak-ci: tests: add a test mode for SANITIZE=leak, run it in CI Makefile: add SANITIZE=leak flag to GIT-BUILD-OPTIONS
2021-10-11Merge branch 'jk/ref-paranoia'Junio C Hamano5-25/+54
The ref iteration code used to optionally allow dangling refs to be shown, which has been tightened up. * jk/ref-paranoia: refs: drop "broken" flag from for_each_fullref_in() ref-filter: drop broken-ref code entirely ref-filter: stop setting FILTER_REFS_INCLUDE_BROKEN repack, prune: drop GIT_REF_PARANOIA settings refs: turn on GIT_REF_PARANOIA by default refs: omit dangling symrefs when using GIT_REF_PARANOIA refs: add DO_FOR_EACH_OMIT_DANGLING_SYMREFS flag refs-internal.h: reorganize DO_FOR_EACH_* flag documentation refs-internal.h: move DO_FOR_EACH_* flags next to each other t5312: be more assertive about command failure t5312: test non-destructive repack t5312: create bogus ref as necessary t5312: drop "verbose" helper t5600: provide detached HEAD for corruption failures t5516: don't use HEAD ref for invalid ref-deletion tests t7900: clean up some more broken refs
2021-10-11Merge branch 'sg/test-split-index-fix'Junio C Hamano4-46/+94
Test updates. * sg/test-split-index-fix: read-cache: fix GIT_TEST_SPLIT_INDEX tests: disable GIT_TEST_SPLIT_INDEX for sparse index tests read-cache: look for shared index files next to the index, too t1600-index: disable GIT_TEST_SPLIT_INDEX t1600-index: don't run git commands upstream of a pipe t1600-index: remove unnecessary redirection
2021-10-11Merge branch 'tb/midx-write-propagate-namehash'Junio C Hamano3-4/+51
"git multi-pack-index write --bitmap" learns to propagate the hashcache from original bitmap to resulting bitmap. * tb/midx-write-propagate-namehash: t5326: test propagating hashcache values p5326: generate pack bitmaps before writing the MIDX bitmap p5326: don't set core.multiPackIndex unnecessarily p5326: create missing 'perf-tag' tag midx.c: respect 'pack.writeBitmapHashcache' when writing bitmaps pack-bitmap.c: propagate namehash values from existing bitmaps t/helper/test-bitmap.c: add 'dump-hashes' mode
2021-10-10userdiff-cpp: learn the C++ spaceship operatorJohannes Sixt1-1/+1
Since C++20, the language has a generalized comparison operator <=>. Teach the cpp driver not to separate it into <= and > tokens. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-10userdiff-cpp: permit the digit-separating single-quote in numbersJohannes Sixt1-4/+4
Since C++17, the single-quote can be used as digit separator: 3.141'592'654 1'000'000 0xdead'beaf Make it known to the word regex of the cpp driver, so that numbers are not split into separate tokens at the single-quotes. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-10userdiff-cpp: prepare test cases with yet unsupported featuresJohannes Sixt3-18/+18
We are going to add support for C++'s digit-separating single-quote and the spaceship operator. By adding the test cases in this separate commit, the effect on the word highlighting will become more obvious as the features are implemented and the file cpp/expect is updated. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-08cat-file: disable refs/replace with --batch-all-objectsJeff King1-0/+66
When we're enumerating all objects in the object database, it doesn't make sense to respect refs/replace. The point of this option is to enumerate all of the objects in the database at a low level. By definition we'd already show the replacement object's contents (under its real oid), and showing those contents under another oid is almost certainly working against what the user is trying to do. Note that you could make the same argument for something like: git show-index <foo.idx | awk '{print $2}' | git cat-file --batch but there we can't know in cat-file exactly what the user intended, because we don't know the source of the input. They could be trying to do low-level debugging, or they could be doing something more high-level (e.g., imagine a porcelain built around cat-file for its object accesses). So in those cases, we'll have to rely on the user specifying "git --no-replace-objects" to tell us what to do. One _could_ make an argument that "cat-file --batch" is sufficiently low-level plumbing that it should not respect replace-objects at all (and the caller should do any replacement if they want it). But we have been doing so for some time. The history is a little tangled: - looking back as far as v1.6.6, we would not respect replace refs for --batch-check, but would for --batch (because the former used sha1_object_info(), and the replace mechanism only affected actual object reads) - this discrepancy was made even weirder by 98e2092b50 (cat-file: teach --batch to stream blob objects, 2013-07-10), where we always output the header using the --batch-check code, and then printed the object separately. This could lead to "cat-file --batch" dying (when it notices the size or type changed for a non-blob object) or even producing bogus output (in streaming mode, we didn't notice that we wrote the wrong number of bytes). - that persisted until 1f7117ef7a (sha1_file: perform object replacement in sha1_object_info_extended(), 2013-12-11), which then respected replace refs for both forms. So it has worked reliably this way for over 7 years, and we should make sure it continues to do so. That could also be an argument that --batch-all-objects should not change behavior (which this patch is doing), but I really consider the current behavior to be an unintended bug. It's a side effect of how the code is implemented (feeding the oids back into oid_object_info() rather than looking at what we found while reading the loose and packed object storage). The implementation is straight-forward: we just disable the global read_replace_refs flag when we're in --batch-all-objects mode. It would perhaps be a little cleaner to change the flag we pass to oid_object_info_extended(), but that's not enough. We also read objects via read_object_file() and stream_blob_to_fd(). The former could switch to its _extended() form, but the streaming code has no mechanism for disabling replace refs. Setting the global flag works, and as a bonus, it's impossible to have any "oops, we're sometimes replacing the object and sometimes not" bugs in the output (like the ones caused by 98e2092b50 above). The tests here cover the regular-input and --batch-all-objects cases, for both --batch-check and --batch. There is a test in t6050 that covers the regular-input case with --batch already, but this new one goes much further in actually verifying the output (plus covering --batch-check explicitly). This is perhaps a little overkill and the tests would be simpler just covering --batch-check, but I wanted to make sure we're checking that --batch output is consistent between the header and the content. The global-flag technique used here makes that easy to get right, but this is future-proofing us against regressions. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-08t1006: clean up broken objectsJeff King1-0/+9
A few of the tests create intentionally broken objects with broken types. Let's clean them up after we're done with them, so that later tests don't get confused (we hadn't noticed because this only affects tests which use --batch-all-objects, but I'm about to add more). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-08submodule: trace adding submodule ODB as alternateJonathan Tan1-5/+2
Submodule ODBs are never added as alternates during the execution of the test suite, but there may be a rare interaction that the test suite does not have coverage of. Add a trace message when this happens, so that users who trace their commands can notice such occurrences. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-08submodule: pass repo to check_has_commit()Jonathan Tan5-0/+15
Pass the repo explicitly when calling check_has_commit() to avoid relying on add_submodule_odb(). With this commit and the parent commit, the last remaining tests no longer rely on add_submodule_odb(), so mark these tests accordingly. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-08merge-{ort,recursive}: remove add_submodule_odb()Jonathan Tan1-0/+3
After the parent commit and some of its ancestors, the only place commits are being accessed through alternates is in the user-facing message formatting code. Fix those, and remove the add_submodule_odb() calls. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-08pretty: colorize pattern matches in commit messagesHamza Mahfooz1-0/+51
The "git log" command limits its output to the commits that contain strings matched by a pattern when the "--grep=<pattern>" option is used, but unlike output from "git grep -e <pattern>", the matches are not highlighted, making them harder to spot. Teach the pretty-printer code to highlight matches from the "--grep=<pattern>", "--author=<pattern>" and "--committer=<pattern>" options (to view the last one, you may have to ask for --pretty=fuller). Also, it must be noted that we are effectively greping the content twice (because it would be a hassle to rework the existing matching code to do a /g match and then pass it all down to the coloring code), however it only slows down "git log --author=^H" on this repository by around 1-2% (compared to v2.33.0), so it should be a small enough slow down to justify the addition of the feature. Signed-off-by: Hamza Mahfooz <someguy@effective-light.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-08parse-options tests: test optname() outputÆvar Arnfjörð Bjarmason1-3/+39
There were no tests for checking the specific output that we'll generate in optname(), let's add some. That output was added back in 4a59fd13122 (Add a simple option parser., 2007-10-15). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-08userdiff-cpp: tighten word regexJohannes Sixt1-8/+8
Generally, word regex can be written such that they match tokens liberally and need not model the actual syntax because it can be assumed that the regex will only be applied to syntactically correct text. The regex for cpp (C/C++) is too liberal, though. It regards these sequences as single tokens: 1+2 1.5-e+2+f and the following amalgams as one token: .l as in str.length .f as in str.find .e as in str.erase Tighten the regex in the following way: - Accept + and - only in one position in the exponent. + and - are no longer regarded as the sign of a number and are treated by the catcher-all that is not visible in the driver's regex. - Accept a leading decimal point only when it is followed by a digit. For readability, factor hex- and binary numbers into an own term. As a drive-by, this fixes that floating point numbers such as 12E5 (with upper-case E) were split into two tokens. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-08t4034: add tests showing problematic cpp tokenizationsJohannes Sixt3-7/+49
The word regex is too loose and matches long streaks of characters that should actually be separate tokens. Add these problematic test cases. Separate the lines with text that will remain identical in the pre- and post-image so that the diff algorithm will not lump removals and additions of consecutive lines together. This makes the expected output easier to read. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-08t4034/cpp: actually test that operator tokens are not splitJohannes Sixt3-60/+39
8d96e7288f2b (t4034: bulk verify builtin word regex sanity, 2010-12-18) added many tests with the intent to verify that operators consisting of more than one symbol are kept together. These are tested by probing a transition from, e.g., a!=b to x!=y, which results in the word-diff [-a-]{+x+}!=[-b-]{+y+} But that proves only that the letters and operators are separate tokens. To prove that != is an unseparable token, we have to probe a transition from, e.g., a=b to a!=b having a word-diff a[-=-]{+!=+}b that proves that the ! is not separate from the =. In the post-image, add to or remove from operators a character that turns it into another valid operator. Change the identifiers used around operators such that the diff algorithm does not have an incentive to match, e.g., a<b in one spot in the pre-image with a<b elsewhere in the post-image. Adjust the expected output to match the new differences. Notice that there are some undesirable tokenizations around e, ., and -. This will be addressed in a later change. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-08test-mergesort: use repeatable random numbersRené Scharfe1-2/+10
Use MINSTD to generate pseudo-random numbers consistently instead of using rand(3), whose output can vary from system to system, and reset its seed before filling in the test values. This gives repeatable results across versions and systems, which simplifies sharing and comparing of results between developers. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-07read-cache: let verify_path() reject trailing dir separators againRené Scharfe1-1/+1
6e773527b6 (sparse-index: convert from full to sparse, 2021-03-30) made verify_path() accept trailing directory separators for directories, which is necessary for sparse directory entries. This clemency causes "git stash" to stumble over sub-repositories, though, and there may be more unintended side-effects. Avoid them by restoring the old verify_path() behavior and accepting trailing directory separators only in places that are supposed to handle sparse directory entries. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-07t3905: show failure to ignore sub-repoRené Scharfe1-0/+6
"git stash" used to ignore sub-repositories until 6e773527b6 (sparse-index: convert from full to sparse, 2021-03-30). Add a test that demonstrates this regression. Reported-by: Robert Leftwich <robert@gitpod.io> Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-07merge: add missing strbuf_release()Ævar Arnfjörð Bjarmason1-0/+1
We strbuf_reset() this "struct strbuf" in a loop earlier, but never freed it. Plugs a memory leak that's been here ever since this code got introduced in 1c7b76be7d6 (Build in merge, 2008-07-07). This takes us from 68 failed tests in "t7600-merge.sh" to 59 under SANITIZE=leak, and makes "t7604-merge-custom-message.sh" pass! Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-07ls-files: add missing string_list_clear()Ævar Arnfjörð Bjarmason1-2/+3
Fix a memory leak that's been here ever since 72aeb18772d (clean.c, ls-files.c: respect encapsulation of exclude_list_groups, 2013-01-16), we dup'd the argument in option_parse_exclude(), but never freed the string_list. This makes almost all of t3001-ls-files-others-exclude.sh pass (it had a lot of failures before). Let's mark it as passing with TEST_PASSES_SANITIZE_LEAK=true, and then exclude the tests that still failed with a !SANITIZE_LEAK prerequisite check until we fix those leaks. We can still see the failed tests under GIT_TEST_FAIL_PREREQS=true. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-07ls-files: fix a trivial dir_clear() leakÆvar Arnfjörð Bjarmason4-0/+5
Fix an edge case that was missed when the dir_clear() call was added in eceba532141 (dir: fix problematic API to avoid memory leaks, 2020-08-18), we need to also clean up when we're about to exit with non-zero. That commit says, on the topic of the dir_clear() API and UNLEAK(): [...]two of them clearly thought about leaks since they had an UNLEAK(dir) directive, which to me suggests that the method to free the data was too unclear. I think that 0e5bba53af7 (add UNLEAK annotation for reducing leak false positives, 2017-09-08) which added the UNLEAK() makes it clear that that wasn't the case, rather it was the desire to avoid the complexity of freeing the memory at the end of the program. This does add a bit of complexity, but I think it's worth it to just fix these leaks when it's easy in built-ins. It allows them to serve as canaries for underlying APIs that shouldn't be leaking, it encourages us to make those freeing APIs nicer for all their users, and it prevents other leaking regressions by being able to mark the entire test as TEST_PASSES_SANITIZE_LEAK=true. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-07tests: fix test-oid-array leak, test in SANITIZE=leakÆvar Arnfjörð Bjarmason2-0/+6
Fix a trivial memory leak present ever since 38d905bf585 (sha1-array: add test-sha1-array and basic tests, 2014-10-01), now that that's fixed we can test this under GIT_TEST_PASSING_SANITIZE_LEAK=true. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-07tests: fix a memory leak in test-oidtree.cÆvar Arnfjörð Bjarmason2-0/+4
Fix a memory leak in t/helper/test-oidtree.c, we were not freeing the "struct strbuf" we used for the stdin input we parsed. This leak has been here ever since 92d8ed8ac10 (oidtree: a crit-bit tree for odb_loose_cache, 2021-07-07). Now that it's fixed we can declare that t0069-oidtree.sh will pass under GIT_TEST_PASSING_SANITIZE_LEAK=true. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-07tests: fix a memory leak in test-parse-options.cÆvar Arnfjörð Bjarmason2-1/+7
Fix a memory leak in t/helper/test-parse-options.c, we were not freeing the allocated "struct string_list" or its items. Let's move the declaration of the "list" variable into the cmd__parse_options() and release it at the end. In c8ba1639165 (parse-options: add OPT_STRING_LIST helper, 2011-06-09) the "list" variable was added, and later on in c8ba1639165 (parse-options: add OPT_STRING_LIST helper, 2011-06-09) the "expect" was added. The "list" variable was last touched in 2721ce21e43 (use string_list initializer consistently, 2016-06-13), but it was still left at the static scope, it's better to move it to the function for consistency. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-07tests: fix a memory leak in test-prio-queue.cÆvar Arnfjörð Bjarmason2-0/+4
Fix a memory leak in t/helper/test-prio-queue.c, the lack of freeing the memory with clear_prio_queue() has been there ever since this code was originally added in b4b594a3154 (prio-queue: priority queue of pointers to structs, 2013-06-06). By fixing this leak we can cleanly run t0009-prio-queue.sh under SANITIZE=leak, so annotate it as such with TEST_PASSES_SANITIZE_LEAK=true. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-07Merge branch 'ab/sanitize-leak-ci' into ab/mark-leak-free-tests-moreJunio C Hamano10-1/+39
* ab/sanitize-leak-ci: tests: add a test mode for SANITIZE=leak, run it in CI Makefile: add SANITIZE=leak flag to GIT-BUILD-OPTIONS
2021-10-07Merge branch 'ab/sanitize-leak-ci' into ab/mark-leak-free-testsJunio C Hamano10-1/+39
* ab/sanitize-leak-ci: tests: add a test mode for SANITIZE=leak, run it in CI Makefile: add SANITIZE=leak flag to GIT-BUILD-OPTIONS
2021-10-07unpack-trees: don't leak memory in verify_clean_subdirectory()Ævar Arnfjörð Bjarmason1-0/+2
Fix two different but related memory leaks in verify_clean_subdirectory(). We leaked both the "pathbuf" if read_directory() returned non-zero, and we never cleaned up our own "struct dir_struct" either. * "pathbuf": When the read_directory() call followed by the free(pathbuf) was added in c81935348be (Fix switching to a branch with D/F when current branch has file D., 2007-03-15) we didn't bother to free() before we called die(). But when this code was later libified in 203a2fe1170 (Allow callers of unpack_trees() to handle failure, 2008-02-07) we started to leak as we returned data to the caller. This fixes that memory leak, which can be observed under SANITIZE=leak with e.g. the "t1001-read-tree-m-2way.sh" test. * "struct dir_struct": We've leaked the dir_struct ever since this code was added back in c81935348be. When that commit was written there wasn't an equivalent of dir_clear(). Since it was added in 270be816049 (dir.c: provide clear_directory() for reclaiming dir_struct memory, 2013-01-06) we've omitted freeing the memory allocated here. This memory leak could also be observed under SANITIZE=leak and the "t1001-read-tree-m-2way.sh" test. This makes all the test in "t1001-read-tree-m-2way.sh" pass under "GIT_TEST_PASSING_SANITIZE_LEAK=true", we'd previously die in tests 25, 26 & 28. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-07Merge branch 'ab/sanitize-leak-ci' into ab/unpack-trees-leakfixJunio C Hamano10-1/+39
* ab/sanitize-leak-ci: tests: add a test mode for SANITIZE=leak, run it in CI Makefile: add SANITIZE=leak flag to GIT-BUILD-OPTIONS
2021-10-07sparse index: fix use-after-free bug in cache_tree_verify()Phillip Wood1-1/+1
In a sparse index it is possible for the tree that is being verified to be freed while it is being verified. This happens when the index is sparse but the cache tree is not and index_name_pos() looks up a path from the cache tree that is a descendant of a sparse index entry. That triggers a call to ensure_full_index() which frees the cache tree that is being verified. Carrying on trying to verify the tree after this results in a use-after-free bug. Instead restart the verification if a sparse index is converted to a full index. This bug is triggered by a call to reset_head() in "git rebase --apply". Thanks to René Scharfe and Derrick Stolee for their help analyzing the problem. ==74345==ERROR: AddressSanitizer: heap-use-after-free on address 0x606000001b20 at pc 0x557cbe82d3a2 bp 0x7ffdfee08090 sp 0x7ffdfee08080 READ of size 4 at 0x606000001b20 thread T0 #0 0x557cbe82d3a1 in verify_one /home/phil/src/git/cache-tree.c:863 #1 0x557cbe82ca9d in verify_one /home/phil/src/git/cache-tree.c:840 #2 0x557cbe82ca9d in verify_one /home/phil/src/git/cache-tree.c:840 #3 0x557cbe82ca9d in verify_one /home/phil/src/git/cache-tree.c:840 #4 0x557cbe830a2b in cache_tree_verify /home/phil/src/git/cache-tree.c:910 #5 0x557cbea53741 in write_locked_index /home/phil/src/git/read-cache.c:3250 #6 0x557cbeab7fdd in reset_head /home/phil/src/git/reset.c:87 #7 0x557cbe72147f in cmd_rebase builtin/rebase.c:2074 #8 0x557cbe5bd151 in run_builtin /home/phil/src/git/git.c:461 #9 0x557cbe5bd151 in handle_builtin /home/phil/src/git/git.c:714 #10 0x557cbe5c0503 in run_argv /home/phil/src/git/git.c:781 #11 0x557cbe5c0503 in cmd_main /home/phil/src/git/git.c:912 #12 0x557cbe5bad28 in main /home/phil/src/git/common-main.c:52 #13 0x7fdd4b82eb24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24) #14 0x557cbe5bcb8d in _start (/home/phil/src/git/git+0x1b9b8d) 0x606000001b20 is located 0 bytes inside of 56-byte region [0x606000001b20,0x606000001b58) freed by thread T0 here: #0 0x7fdd4bacff19 in __interceptor_free /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:127 #1 0x557cbe82af60 in cache_tree_free /home/phil/src/git/cache-tree.c:35 #2 0x557cbe82aee5 in cache_tree_free /home/phil/src/git/cache-tree.c:31 #3 0x557cbe82aee5 in cache_tree_free /home/phil/src/git/cache-tree.c:31 #4 0x557cbe82aee5 in cache_tree_free /home/phil/src/git/cache-tree.c:31 #5 0x557cbeb2557a in ensure_full_index /home/phil/src/git/sparse-index.c:310 #6 0x557cbea45c4a in index_name_stage_pos /home/phil/src/git/read-cache.c:588 #7 0x557cbe82ce37 in verify_one /home/phil/src/git/cache-tree.c:850 #8 0x557cbe82ca9d in verify_one /home/phil/src/git/cache-tree.c:840 #9 0x557cbe82ca9d in verify_one /home/phil/src/git/cache-tree.c:840 #10 0x557cbe82ca9d in verify_one /home/phil/src/git/cache-tree.c:840 #11 0x557cbe830a2b in cache_tree_verify /home/phil/src/git/cache-tree.c:910 #12 0x557cbea53741 in write_locked_index /home/phil/src/git/read-cache.c:3250 #13 0x557cbeab7fdd in reset_head /home/phil/src/git/reset.c:87 #14 0x557cbe72147f in cmd_rebase builtin/rebase.c:2074 #15 0x557cbe5bd151 in run_builtin /home/phil/src/git/git.c:461 #16 0x557cbe5bd151 in handle_builtin /home/phil/src/git/git.c:714 #17 0x557cbe5c0503 in run_argv /home/phil/src/git/git.c:781 #18 0x557cbe5c0503 in cmd_main /home/phil/src/git/git.c:912 #19 0x557cbe5bad28 in main /home/phil/src/git/common-main.c:52 #20 0x7fdd4b82eb24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24) previously allocated by thread T0 here: #0 0x7fdd4bad0459 in __interceptor_calloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154 #1 0x557cbebc1807 in xcalloc /home/phil/src/git/wrapper.c:140 #2 0x557cbe82b7d8 in cache_tree /home/phil/src/git/cache-tree.c:17 #3 0x557cbe82b7d8 in prime_cache_tree_rec /home/phil/src/git/cache-tree.c:763 #4 0x557cbe82b837 in prime_cache_tree_rec /home/phil/src/git/cache-tree.c:764 #5 0x557cbe82b837 in prime_cache_tree_rec /home/phil/src/git/cache-tree.c:764 #6 0x557cbe8304e1 in prime_cache_tree /home/phil/src/git/cache-tree.c:779 #7 0x557cbeab7fa7 in reset_head /home/phil/src/git/reset.c:85 #8 0x557cbe72147f in cmd_rebase builtin/rebase.c:2074 #9 0x557cbe5bd151 in run_builtin /home/phil/src/git/git.c:461 #10 0x557cbe5bd151 in handle_builtin /home/phil/src/git/git.c:714 #11 0x557cbe5c0503 in run_argv /home/phil/src/git/git.c:781 #12 0x557cbe5c0503 in cmd_main /home/phil/src/git/git.c:912 #13 0x557cbe5bad28 in main /home/phil/src/git/common-main.c:52 #14 0x7fdd4b82eb24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24) Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-07test-read-midx: fix leak of bitmap_index structJeff King1-2/+6
In read_midx_preferred_pack(), we open the bitmap index but never free it. This isn't a big deal since this is just a test helper, and we exit immediately after, but since we're trying to keep our leak-checking tidy now, it's worth fixing. Signed-off-by: Jeff King <peff@peff.net> Acked-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-06Merge branch 'lh/systemd-timers'Junio C Hamano1-2/+1
Testfix. * lh/systemd-timers: maintenance: fix test t7900-maintenance.sh