summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2022-03-25t7700: check post-condition in kept-pack testLibravatar Derrick Stolee1-3/+54
The '--write-midx -b packs non-kept objects' test in t7700-repack.sh uses test_subcommand_inexact to check that 'git repack' properly adds the '--honor-pack-keep' flag to the 'git pack-objects' subcommand. However, the test_subcommand_inexact helper is more flexible than initially designed, and this instance is the only one that makes use of it: there are additional arguments between 'git pack-objects' and the '--honor-pack-keep' flag. In order to make test_subcommand_inexact more strict, we need to fix this instance. This test checks that 'git repack --write-midx -a -b -d' will create a new pack-file that does not contain the objects within the kept pack. This behavior is possible because of the multi-pack-index bitmap that will bitmap objects against multiple packs. Without --write-midx, the objects in the kept pack would be duplicated so the resulting pack is closed under reachability and bitmaps can be created against it. This is discussed in more detail in e4d0c11c0 (repack: respect kept objects with '--write-midx -b', 2021-12-20) which also introduced this instance of test_subcommand_inexact. To better verify the intended post-conditions while also removing this instance of test_subcommand_inexact, rewrite the test to check the list of packed objects in the kept pack and the list of the objects in the newly-repacked pack-file _other_ than the kept pack. These lists should be disjoint. Be sure to include a non-kept pack-file and loose objects to be extra careful that this is properly behaving with kept packs and not just avoiding repacking all pack-files. Co-authored-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-24test-lib: have --immediate emit valid TAP on failureLibravatar Ævar Arnfjörð Bjarmason2-1/+18
Change the "--immediate" option so that it emits valid TAP on failure. Before this it would omit the required plan at the end, e.g. under SANITIZE=leak we'd show a "No plan found in TAP output" error from "prove": $ prove t0006-date.sh :: --immediate t0006-date.sh .. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/22 subtests Test Summary Report ------------------- t0006-date.sh (Wstat: 256 Tests: 22 Failed: 1) Failed test: 22 Non-zero exit status: 1 Parse errors: No plan found in TAP output Files=1, Tests=22, 0 wallclock secs ( 0.02 usr 0.01 sys + 0.18 cusr 0.06 csys = 0.27 CPU) Result: FAIL Now we'll emit output that doesn't result in TAP parsing failures: $ prove t0006-date.sh :: --immediate t0006-date.sh .. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/22 subtests Test Summary Report ------------------- t0006-date.sh (Wstat: 256 Tests: 22 Failed: 1) Failed test: 22 Non-zero exit status: 1 Files=1, Tests=22, 0 wallclock secs ( 0.02 usr 0.00 sys + 0.19 cusr 0.05 csys = 0.26 CPU) Result: FAIL Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-24Sync with 2.34.2Libravatar Johannes Schindelin1-6/+14
* maint-2.34: Git 2.34.2 Git 2.33.2 Git 2.32.1 Git 2.31.2 GIT-VERSION-GEN: bump to v2.33.1 Git 2.30.3 setup_git_directory(): add an owner check for the top-level directory Add a function to determine whether a path is owned by the current user
2022-03-24Sync with 2.33.2Libravatar Johannes Schindelin1-6/+14
* maint-2.33: Git 2.33.2 Git 2.32.1 Git 2.31.2 GIT-VERSION-GEN: bump to v2.33.1 Git 2.30.3 setup_git_directory(): add an owner check for the top-level directory Add a function to determine whether a path is owned by the current user
2022-03-24Sync with 2.32.1Libravatar Johannes Schindelin1-6/+14
* maint-2.32: Git 2.32.1 Git 2.31.2 Git 2.30.3 setup_git_directory(): add an owner check for the top-level directory Add a function to determine whether a path is owned by the current user
2022-03-24Sync with 2.31.2Libravatar Johannes Schindelin1-6/+14
* maint-2.31: Git 2.31.2 Git 2.30.3 setup_git_directory(): add an owner check for the top-level directory Add a function to determine whether a path is owned by the current user
2022-03-24Sync with 2.30.3Libravatar Johannes Schindelin1-6/+14
* maint-2.30: Git 2.30.3 setup_git_directory(): add an owner check for the top-level directory Add a function to determine whether a path is owned by the current user
2022-03-24Fix `GIT_CEILING_DIRECTORIES` with `C:\` and the likesLibravatar Johannes Schindelin1-6/+14
When determining the length of the longest ancestor of a given path with respect to to e.g. `GIT_CEILING_DIRECTORIES`, we special-case the root directory by returning 0 (i.e. we pretend that the path `/` does not end in a slash by virtually stripping it). That is the correct behavior because when normalizing paths, the root directory is special: all other directory paths have their trailing slash stripped, but not the root directory's path (because it would become the empty string, which is not a legal path). However, this special-casing of the root directory in `longest_ancestor_length()` completely forgets about Windows-style root directories, e.g. `C:\`. These _also_ get normalized with a trailing slash (because `C:` would actually refer to the current directory on that drive, not necessarily to its root directory). In fc56c7b34b (mingw: accomodate t0060-path-utils for MSYS2, 2016-01-27), we almost got it right. We noticed that `longest_ancestor_length()` expects a slash _after_ the matched prefix, and if the prefix already ends in a slash, the normalized path won't ever match and -1 is returned. But then that commit went astray: The correct fix is not to adjust the _tests_ to expect an incorrect -1 when that function is fed a prefix that ends in a slash, but instead to treat such a prefix as if the trailing slash had been removed. Likewise, that function needs to handle the case where it is fed a path that ends in a slash (not only a prefix that ends in a slash): if it matches the prefix (plus trailing slash), we still need to verify that the path does not end there, otherwise the prefix is not actually an ancestor of the path but identical to it (and we need to return -1 in that case). With these two adjustments, we no longer need to play games in t0060 where we only add `$rootoff` if the passed prefix is different from the MSYS2 pseudo root, instead we also add it for the MSYS2 pseudo root itself. We do have to be careful to skip that logic entirely for Windows paths, though, because they do are not subject to that MSYS2 pseudo root treatment. This patch fixes the scenario where a user has set `GIT_CEILING_DIRECTORIES=C:\`, which would be ignored otherwise. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2022-03-23reflog [show]: display sensible -h outputLibravatar Ævar Arnfjörð Bjarmason1-0/+5
Change the "git reflog show -h" output to show the usage summary relevant to it, rather than displaying the same output that "git log -h" would show. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-23reflog: convert to parse_options() APILibravatar Ævar Arnfjörð Bjarmason2-1/+18
Continue the work started in 33d7bdd6459 (builtin/reflog.c: use parse-options api for expire, delete subcommands, 2022-01-06) and convert the cmd_reflog() function itself to use the parse_options() API. Let's also add a test which would fail if we forgot PARSE_OPT_NO_INTERNAL_HELP here, as well as making sure that we'll still pass through "--" by supplying PARSE_OPT_KEEP_DASHDASH. For that test we need to change "test_commit()" to accept files starting with "--". The "git reflog -h" usage will now show the usage for all of the sub-commands, rather than a terse summary which wasn't correct (e.g. "git reflog exists" is not a valid command). See my 8757b35d443 (commit-graph: define common usage with a macro, 2021-08-23) for prior art. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-23reset: remove 'reset.refresh' config optionLibravatar Victoria Dye1-12/+2
Remove the 'reset.refresh' option, requiring that users explicitly specify '--no-refresh' if they want to skip refreshing the index. The 'reset.refresh' option was introduced in 101cee42dd (reset: introduce --[no-]refresh option to --mixed, 2022-03-11) as a replacement for the refresh-skipping behavior originally controlled by 'reset.quiet'. Although 'reset.refresh=false' functionally served the same purpose as 'reset.quiet=true', it exposed [1] the fact that the existence of a global "skip refresh" option could potentially cause problems for users. Allowing a global config option to avoid refreshing the index forces scripts using 'git reset --mixed' to defensively use '--refresh' if index refresh is expected; if that option is missing, behavior of a script could vary from user-to-user without explanation. Furthermore, globally disabling index refresh in 'reset --mixed' was initially devised as a passive performance improvement; since the introduction of the option, other changes have been made to Git (e.g., the sparse index) with a greater potential performance impact without sacrificing index correctness. Therefore, we can more aggressively err on the side of correctness and limit the cases of skipping index refresh to only when a user specifies the '--no-refresh' option. [1] https://lore.kernel.org/git/xmqqy2179o3c.fsf@gitster.g/ Signed-off-by: Victoria Dye <vdye@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-23reset: remove 'reset.quiet' config optionLibravatar Victoria Dye1-2/+1
Remove the 'reset.quiet' config option, remove '--no-quiet' documentation in 'Documentation/git-reset.txt'. In 4c3abd0551 (reset: add new reset.quiet config setting, 2018-10-23), 'reset.quiet' was introduced as a way to globally change the default behavior of 'git reset --mixed' to skip index refresh. However, now that '--quiet' does not affect index refresh, 'reset.quiet' would only serve to globally silence logging. This was not the original intention of the config setting, and there's no precedent for such a setting in other commands with a '--quiet' option, so it appears to be obsolete. In addition to the options & its documentation, remove 'reset.quiet' from the recommended config for 'scalar'. Signed-off-by: Victoria Dye <vdye@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-23reset: do not make '--quiet' disable index refreshLibravatar Victoria Dye1-27/+5
Update '--quiet' to no longer implicitly skip refreshing the index in a mixed reset. Users now have the ability to explicitly disable refreshing the index with the '--no-refresh' option, so they no longer need to use '--quiet' to do so. Moreover, we explicitly remove the refresh-skipping behavior from '--quiet' because it is completely unrelated to the stated purpose of the option: "Be quiet, only report errors." Helped-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Victoria Dye <vdye@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-23Merge branch 'ab/plug-random-leaks'Libravatar Junio C Hamano1-2/+10
Double-free fix for a recently merged topic. * ab/plug-random-leaks: diff.c: fix a double-free regression in a18d66cefb tests: demonstrate "show --word-diff --color-moved" regression
2022-03-23Merge branch 'jc/cat-file-batch-default-format-optim'Libravatar Junio C Hamano1-0/+12
Optimize away strbuf_expand() call with a hardcoded formatting logic specific for the default format in the --batch and --batch-check options of "git cat-file". * jc/cat-file-batch-default-format-optim: cat-file: skip expanding default format
2022-03-23Merge branch 'ac/test-lazy-fetch'Libravatar Junio C Hamano1-0/+19
A new test to ensure a lazy fetching is not triggered when it should not be. * ac/test-lazy-fetch: partial-clone: add a partial-clone test case
2022-03-23Merge branch 'ps/repack-with-server-info'Libravatar Junio C Hamano1-0/+50
"git repack" learned a new configuration to disable triggering of age-old "update-server-info" command, which is rarely useful these days. * ps/repack-with-server-info: repack: add config to skip updating server info repack: refactor to avoid double-negation of update-server-info
2022-03-23Merge branch 'ab/reflog-prep-fix'Libravatar Junio C Hamano1-0/+9
Regression fix. * ab/reflog-prep-fix: reflog: don't be noisy on empty reflogs
2022-03-23Merge branch 'ep/remove-duplicated-includes'Libravatar Junio C Hamano1-1/+0
Code clean-up. * ep/remove-duplicated-includes: attr.h: remove duplicate struct definition t/helper/test-run-command.c: delete duplicate include builtin/stash.c: delete duplicate include builtin/sparse-checkout.c: delete duplicate include builtin/gc.c: delete duplicate include attr.c: delete duplicate include
2022-03-23Merge branch 'ep/t6423-modernize'Libravatar Junio C Hamano1-5/+5
Code clean-up. * ep/t6423-modernize: t6423-merge-rename-directories.sh: use the $(...) construct
2022-03-23Merge branch 'jk/name-rev-w-genno'Libravatar Junio C Hamano1-0/+118
"git name-rev" learned to use the generation numbers when setting the lower bound of searching commits used to explain the revision, when available, instead of committer time. * jk/name-rev-w-genno: name-rev: use generation numbers if available
2022-03-23Merge branch 'jd/userdiff-kotlin'Libravatar Junio C Hamano13-0/+153
A new built-in userdiff driver for kotlin. * jd/userdiff-kotlin: userdiff: add builtin diff driver for kotlin language.
2022-03-23Merge branch 'gc/submodule-update-part1'Libravatar Junio C Hamano2-3/+37
Rewrite of "git submodule update" in C (early part). * gc/submodule-update-part1: submodule--helper update-clone: check for --filter and --init submodule update: add tests for --filter submodule--helper: remove ensure-core-worktree submodule--helper update-clone: learn --init submodule--helper: allow setting superprefix for init_submodule() submodule--helper: refactor get_submodule_displaypath() submodule--helper run-update-procedure: learn --remote submodule--helper: don't use bitfield indirection for parse_options() submodule--helper: get remote names from any repository submodule--helper run-update-procedure: remove --suboid submodule--helper: reorganize code for sh to C conversion submodule--helper: remove update-module-mode submodule tests: test for init and update failure output
2022-03-23bundle: output hash information in 'verify'Libravatar Derrick Stolee1-7/+17
The previous change moved the 'filter' capability to the end of the 'git bundle verify' output. Now, add the 'object-format' capability to the output, when it exists. This change makes 'git bundle verify' output the hash used in all cases, even if the capability is not in the bundle. This means that v2 bundles will always output that they use "sha1". This might look noisy to some users, but it does simplify the implementation and the test strategy for this feature. Since 'verify' ends early when a prerequisite commit is missing, we need to insert this hash message carefully into our expected test output throughout t6020. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-23bundle: move capabilities to end of 'verify'Libravatar Derrick Stolee1-1/+1
The 'filter' capability was added in 105c6f14a (bundle: parse filter capability, 2022-03-09), but was added in a strange place in the 'git bundle verify' output. The tests for this show output like the following: The bundle contains these 2 refs: <COMMIT1> <REF1> <COMMIT2> <REF2> The bundle uses this filter: blob:none The bundle records a complete history. This looks very odd if we have a thin bundle that contains boundary commits instead of a complete history: The bundle contains these 2 refs: <COMMIT1> <REF1> <COMMIT2> <REF2> The bundle uses this filter: blob:none The bundle requires these 2 refs: <COMMIT3> <COMMIT4> This separation between tip refs and boundary refs is unfortunate. Move the filter capability output to the end of the output. Update the documentation to match. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-23ls-tree: detect and error on --name-only --name-statusLibravatar Ævar Arnfjörð Bjarmason1-6/+9
The --name-only and --name-status options are synonyms, but let's detect and error if both are provided. In addition let's add explicit --format tests for the combination of these various options. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Teng Long <dyroneteng@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-23ls-tree: support --object-only option for "git-ls-tree"Libravatar Teng Long2-2/+14
'--object-only' is an alias for '--format=%(objectname)'. It cannot be used together other format-altering options like '--name-only', '--long' or '--format', they are mutually exclusive. The "--name-only" option outputs <filepath> only. Likewise, <objectName> is another high frequency used field, so implement '--object-only' option will bring intuitive and clear semantics for this scenario. Using '--format=%(objectname)' we can achieve a similar effect, but the former is with a lower learning cost(without knowing the format requirement of '--format' option). Even so, if a user is prefer to use "--format=%(objectname)", this is entirely welcome because they are not only equivalent in function, but also have almost identical performance. The reason is this commit also add the specific of "--format=%(objectname)" to the current fast-pathes (builtin formats) to avoid running unnecessary parsing mechanisms. The following performance benchmarks are based on torvalds/linux.git: When hit the fast-path: Benchmark 1: /opt/git/ls-tree-oid-only/bin/git ls-tree -r --object-only HEAD Time (mean ± σ): 83.6 ms ± 2.0 ms [User: 59.4 ms, System: 24.1 ms] Range (min … max): 80.4 ms … 87.2 ms 35 runs Benchmark 1: /opt/git/ls-tree-oid-only/bin/git ls-tree -r --format='%(objectname)' HEAD Time (mean ± σ): 84.1 ms ± 1.8 ms [User: 61.7 ms, System: 22.3 ms] Range (min … max): 80.9 ms … 87.5 ms 35 runs But for a customized format, it will be slower: Benchmark 1: /opt/git/ls-tree-oid-only/bin/git ls-tree -r --format='oid: %(objectname)' HEAD Time (mean ± σ): 96.5 ms ± 2.5 ms [User: 72.9 ms, System: 23.5 ms] Range (min … max): 93.1 ms … 104.1 ms 31 runs Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Teng Long <dyroneteng@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-23ls-tree: introduce "--format" optionLibravatar Ævar Arnfjörð Bjarmason1-0/+67
Add a --format option to ls-tree. It has an existing default output, and then --long and --name-only options to emit the default output along with the objectsize and, or to only emit object paths. Rather than add --type-only, --object-only etc. we can just support a --format using a strbuf_expand() similar to "for-each-ref --format". We might still add such options in the future for convenience. The --format implementation is slower than the existing code, but this change does not cause any performance regressions. We'll leave the existing show_tree() unchanged, and only run show_tree_fmt() in if a --format different than the hardcoded built-in ones corresponding to the existing modes is provided. I.e. something like the "--long" output would be much slower with this, mainly due to how we need to allocate various things to do with quote.c instead of spewing the output directly to stdout. The new option of '--format' comes from Ævar Arnfjörð Bjarmasonn's idea and suggestion, this commit makes modifications in terms of the original discussion on community [1]. In [1] there was a "GIT_TEST_LS_TREE_FORMAT_BACKEND" variable to ensure that we had test coverage for passing tests that would otherwise use show_tree() through show_tree_fmt(), and thus that the formatting mechanism could handle all the same cases as the non-formatting options. Somewhere in subsequent re-rolls of that we seem to have drifted away from what the goal of these tests should be. We're trying to ensure correctness of show_tree_fmt(). We can't tell if we "hit [the] fast-path" here, and instead of having an explicit test for that, we can just add it to something our "test_ls_tree_format" tests for. Here is the statistics about performance tests: 1. Default format (hitten the builtin formats): "git ls-tree <tree-ish>" vs "--format='%(mode) %(type) %(object)%x09%(file)'" $hyperfine --warmup=10 "/opt/git/master/bin/git ls-tree -r HEAD" Benchmark 1: /opt/git/master/bin/git ls-tree -r HEAD Time (mean ± σ): 105.2 ms ± 3.3 ms [User: 84.3 ms, System: 20.8 ms] Range (min … max): 99.2 ms … 113.2 ms 28 runs $hyperfine --warmup=10 "/opt/git/ls-tree-oid-only/bin/git ls-tree -r --format='%(mode) %(type) %(object)%x09%(file)' HEAD" Benchmark 1: /opt/git/ls-tree-oid-only/bin/git ls-tree -r --format='%(mode) %(type) %(object)%x09%(file)' HEAD Time (mean ± σ): 106.4 ms ± 2.7 ms [User: 86.1 ms, System: 20.2 ms] Range (min … max): 100.2 ms … 110.5 ms 29 runs 2. Default format includes object size (hitten the builtin formats): "git ls-tree -l <tree-ish>" vs "--format='%(mode) %(type) %(object) %(size:padded)%x09%(file)'" $hyperfine --warmup=10 "/opt/git/master/bin/git ls-tree -r -l HEAD" Benchmark 1: /opt/git/master/bin/git ls-tree -r -l HEAD Time (mean ± σ): 335.1 ms ± 6.5 ms [User: 304.6 ms, System: 30.4 ms] Range (min … max): 327.5 ms … 348.4 ms 10 runs $hyperfine --warmup=10 "/opt/git/ls-tree-oid-only/bin/git ls-tree -r --format='%(mode) %(type) %(object) %(size:padded)%x09%(file)' HEAD" Benchmark 1: /opt/git/ls-tree-oid-only/bin/git ls-tree -r --format='%(mode) %(type) %(object) %(size:padded)%x09%(file)' HEAD Time (mean ± σ): 337.2 ms ± 8.2 ms [User: 309.2 ms, System: 27.9 ms] Range (min … max): 328.8 ms … 349.4 ms 10 runs Links: [1] https://public-inbox.org/git/RFC-patch-6.7-eac299f06ff-20211217T131635Z-avarab@gmail.com/ [2] https://lore.kernel.org/git/cb717d08be87e3239117c6c667cb32caabaad33d.1646390152.git.dyroneteng@gmail.com/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Teng Long <dyroneteng@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-23ls-tree: fix "--name-only" and "--long" combined use bugLibravatar Teng Long1-0/+9
If we execute "git ls-tree" with combined "--name-only" and "--long" , only the pathname will be printed, the size is omitted (the original discoverer was Peff in [1]). This commit fix this issue by using `OPT_CMDMODE()` instead to make both of them mutually exclusive. [1] https://public-inbox.org/git/YZK0MKCYAJmG+pSU@coredump.intra.peff.net/ Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Teng Long <dyroneteng@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-23ls-tree tests: add tests for --name-statusLibravatar Ævar Arnfjörð Bjarmason1-26/+29
The --name-status synonym for --name-only added in c639a5548a5 (ls-tree: --name-only, 2005-12-01) had no tests, let's make sure it works the same way as its sibling. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Teng Long <dyroneteng@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-21Merge branch 'jy/gitweb-no-need-for-meta'Libravatar Junio C Hamano1-1/+14
Remove unneeded <meta http-equiv=content-type...> from gitweb output. * jy/gitweb-no-need-for-meta: gitweb: remove invalid http-equiv="content-type" comment: fix typo
2022-03-21Merge branch 'ds/partial-bundles'Libravatar Junio C Hamano2-1/+77
Bundle file format gets extended to allow a partial bundle, filtered by similar criteria you would give when making a partial/lazy clone. * ds/partial-bundles: clone: fail gracefully when cloning filtered bundle bundle: unbundle promisor packs bundle: create filtered bundles rev-list: move --filter parsing into revision.c bundle: parse filter capability list-objects: handle NULL function pointers MyFirstObjectWalk: update recommended usage list-objects: consolidate traverse_commit_list[_filtered] pack-bitmap: drop filter in prepare_bitmap_walk() pack-objects: use rev.filter when possible revision: put object filter into struct rev_info list-objects-filter-options: create copy helper index-pack: document and test the --promisor option
2022-03-21Merge branch 'ep/test-malloc-check-with-glibc-2.34'Libravatar Junio C Hamano1-0/+18
The method to trigger malloc check used in our tests no longer work with newer versions of glibc. * ep/test-malloc-check-with-glibc-2.34: test-lib: declare local variables as local test-lib.sh: Use GLIBC_TUNABLES instead of MALLOC_CHECK_ on glibc >= 2.34
2022-03-21Merge branch 'sm/no-git-in-upstream-of-pipe-in-tests'Libravatar Junio C Hamano7-45/+72
Test fixes. * sm/no-git-in-upstream-of-pipe-in-tests: t0030-t0050: avoid pipes with Git on LHS t0001-t0028: avoid pipes with Git on LHS t0003: avoid pipes with Git on LHS
2022-03-18rebase: set REF_HEAD_DETACH in checkout_up_to_date()Libravatar John Cai1-0/+9
"git rebase A B" where B is not a commit should behave as if the HEAD got detached at B and then the detached HEAD got rebased on top of A. A bug however overwrites the current branch to point at B, when B is a descendant of A (i.e. the rebase ends up being a fast-forward). See [1] for the original bug report. The callstack from checkout_up_to_date() is the following: cmd_rebase() -> checkout_up_to_date() -> reset_head() -> update_refs() -> update_ref() When B is not a valid branch but an oid, rebase sets the head_name of rebase_options to NULL. This value gets passed down this call chain through the branch member of reset_head_opts also getting set to NULL all the way to update_refs(). Then update_refs() checks ropts.branch to decide whether or not to switch branches. If ropts.branch is NULL, it calls update_ref() to update HEAD. At this point however, from rebase's point of view, we want a detached HEAD. But, since checkout_up_to_date() does not set the RESET_HEAD_DETACH flag, the update_ref() call will deference HEAD and update the branch its pointing to. We want the HEAD detached at B instead. Fix this bug by adding the RESET_HEAD_DETACH flag in checkout_up_to_date if B is not a valid branch, so that once reset_head() calls update_refs(), it calls update_ref() with REF_NO_DEREF which updates HEAD directly intead of deferencing it and updating the branch that HEAD points to. Also add a test to ensure the correct behavior. [1] https://lore.kernel.org/git/YiokTm3GxIZQQUow@newk/ Reported-by: Michael McClimon <michael@mcclimon.org> Signed-off-by: John Cai <johncai86@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-18rebase: use test_commit helper in setupLibravatar John Cai1-7/+2
To prepare for the next commit that will test rebase with oids instead of branch names, update the rebase setup test to add a couple of tags we can use. This uses the test_commit helper so we can replace some lines that add a commit manually. Setting logAllRefUpdates is not necessary because it's on by default for repositories with a working tree. Helped-by: Phillip Wood <phillip.wood123@gmail.com> Signed-off-by: John Cai <johncai86@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-17reflog exists: use parse_options() APILibravatar Ævar Arnfjörð Bjarmason1-0/+5
Change the "reflog exists" command added in afcb2e7a3b8 (git-reflog: add exists command, 2015-07-21) to use parse_options() instead of its own custom command-line parser. This continues work started in 33d7bdd6459 (builtin/reflog.c: use parse-options api for expire, delete subcommands, 2022-01-06). As a result we'll understand the --end-of-options synonym for "--", so let's test for that. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-17reflog tests: add missing "git reflog exists" testsLibravatar Ævar Arnfjörð Bjarmason2-5/+32
There were a few "git reflog exists" tests scattered over the test suite, but let's consolidate the testing of the main functionality into a new test file. This makes it easier to run just these tests during development. To do that amend and extend an existing test added in afcb2e7a3b8 (git-reflog: add exists command, 2015-07-21). Let's use "test_must_fail" instead of "!" (in case it segfaults), and test for basic usage, an unknown option etc. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-17shallow: reset commit grafts when shallow is resetLibravatar Jonathan Tan1-0/+9
When reset_repository_shallow() is called, Git clears its cache of shallow information, so that if shallow information is re-requested, Git will read fresh data from disk instead of reusing its stale cached data. However, the cache of commit grafts is not likewise cleared, even though there are commit grafts created from shallow information. This means that if on-disk shallow information were to be updated and then a commit-graft-using codepath were run (for example, a revision walk), Git would be using stale commit graft information. This can be seen from the test in this patch, in which Git performs a revision walk (to check for changed submodules) after a fetch with --update-shallow. Therefore, clear the cache of commit grafts whenever reset_repository_shallow() is called. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-17http tests: use "test_hook" for "smart" and "dumb" http testsLibravatar Ævar Arnfjörð Bjarmason2-21/+14
Change the http tests to use "test_hook" insteadd of "write_script". In both cases we can get rid of sub-shelling. For "t/t5550-http-fetch-dumb.sh" add a trivial helper which sets up the hook and calls "update-server-info". Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-17proc-receive hook tests: use "test_hook" instead of "write_script"Libravatar Ævar Arnfjörð Bjarmason26-67/+67
Change the t5411/*.sh tests to use the test_hook helper instead of "write_script". Unfortunately these tests do the setup and test across different test_expect_success blocks, so we have to use --clobber (implying --setup) for these. Let's change those that can use a quoted here-doc to do so while we're at it. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-17tests: extend "test_hook" for "rm" and "chmod -x", convert "$HOOK"Libravatar Ævar Arnfjörð Bjarmason8-163/+165
Extend the "test_hook" function to take options to disable and remove hooks. Using the wrapper instead of getting the path and running "chmod -x" or "rm" will make it easier to eventually emulate the same behavior with config-based hooks. Not all of these tests need that new mode, but since the rest are either closely related or use the same "$HOOK" pattern let's convert them too. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-17unpack-trees: increment cache_bottom for sparse directoriesLibravatar Victoria Dye1-3/+3
Correct tracking of the 'cache_bottom' for cases where sparse directories are present in the index. BACKGROUND ---------- The 'unpack_trees_options.cache_bottom' is a variable that tracks the in-progress "bottom" of the cache as 'unpack_trees()' iterates through the contents of the index. Most importantly, this value informs the sequential return values of 'next_cache_entry()' which, in the "diff cache" usage of 'unpack_callback()', are either unpacked as-is or are passed into the diff machinery. The 'cache_bottom' is intended to track the position of the first entry in the index that has not yet been diffed or unpacked. It is advanced in two main ways: either it is incremented when an index entry is marked as "used" (in 'mark_ce_used()'), indicating that it was unpacked or diffed, or when a directory is unpacked, in which case it is increased by an amount equaling the number of index entries inside that tree. In 17a1bb570b (unpack-trees: preserve cache_bottom, 2021-07-14), it was identified that sparse directories posed a problem to the above 'cache_bottom' advancement logic - because a sparse directory was both an index entry that could be "used" and a directory that can be unpacked, the 'cache_bottom' would be incremented too many times. To solve this problem, the 'mark_ce_used()' advancement of 'cache_bottom' was skipped for sparse directories. INCORRECT CACHE_BOTTOM TRACKING ------------------------------- Skipping the 'cache_bottom' advancement for sparse directories in 'mark_ce_used()' breaks down in two cases: 1. When the 'unpack_trees()' operation is *not* a "cache diff" (because the directory contents-based incrementing of 'cache_bottom' does not happen). 2. When a cache diff is performed with a pathspec (because 'unpack_index_entry()' will unpack a sparse directory not matched by the pathspec without performing the directory contents-based increment). The former luckily does not appear to affect 'git' behavior, likely because 'cache_bottom' is largely unused (non-"cache diff" 'unpack_trees()' uses 'find_index_entry()' - rather than 'next_cache_entry()' - to find the index entries to unpack). The latter, however, causes 'cache_bottom' to "lag behind" its intended position by an amount equal to the number of sparse directories unpacked so far with 'unpack_index_entry()'. If a repository is structured such that any sparse directories are ordered lexicographically *after* any pathspec-matching directories, though, this issue won't present any adverse behavior. This was the case with the 't1092-sparse-checkout-compatibility.sh' tests before the addition of the 'before/' sparse directory (ordered *before* the in-cone 'deep/' directory), therefore sidestepping the issue. Once the 'before/' directory was added, though, 'cache_bottom' began to lag behind its intended position, causing 'next_cache_entry()' to return index entries it had already processed and, ultimately, an incorrect diff. CORRECTING CACHE_BOTTOM ----------------------- The problems observed in 't1092' come from 'cache_bottom' lagging behind in cases where the cache tree-based advancement doesn't occur. To solve this, then, the fix in 17a1bb570b is "reversed"; rather than skipping 'cache_bottom' advancement in 'mark_ce_used()', we skip the directory contents-based advancement for sparse directories. Now, every index entry can be accounted for in 'cache_bottom': * if you're working with a single index entry, 'cache_bottom' is incremented in 'mark_ce_used()' * if you're working with a directory that contains index entries (but is not one itself), 'cache_bottom' is incremented by the number of entries in that directory. Finally, change the 'test_expect_failure' tests in 't1092' failing due to this bug back to 'test_expect_success'. Signed-off-by: Victoria Dye <vdye@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-17t1092: add sparse directory before cone in test repoLibravatar Victoria Dye1-4/+9
Add a sparse directory 'before/' containing files 'a' and 'b' to the test repo used in 't/t1092-sparse-checkout-compatibility.sh'. This is meant to ensure that no sparse index integrations rely on the in-cone path(s) being lexicographically first in the repo. Unfortunately, some existing tests do not handle this repo architecture properly: * 'add outside sparse cone' * 'status/add: outside sparse cone' * 'reset with pathspecs inside sparse definition' All three of these are due to the incorrect handling of the 'unpack_trees_options.cache_bottom' when performing a cache diff via 'unpack_trees'. This will be corrected in a future patch; in the meantime, mark the tests with 'test_expect_failure'. Finally, update the 'ls-files' and 'root directory cannot be sparse' tests to include the 'before/' directory in their expected index contents. Co-authored-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Victoria Dye <vdye@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-17diff.c: fix a double-free regression in a18d66cefbLibravatar Ævar Arnfjörð Bjarmason1-2/+4
My a18d66cefb9 (diff.c: free "buf" in diff_words_flush(), 2022-03-04) has what it retrospect is a rather obvious bug (I don't know what I was thinking, if it all): We use the "emitted_symbols" allocation in append_emitted_diff_symbol() N times, but starting with a18d66cefb9 we'd free it after its first use! The correct way to free this data would have been to add the free() to the existing free_diff_words_data() function, so let's do that. The "ecbdata->diff_words->opt->emitted_symbols" might be NULL, so let's add a trivial free_emitted_diff_symbols() helper next to the function that appends to it. This fixes the "no effect on show from" leak tested for in the preceding commit. Perhaps confusingly this change will skip that test under SANITIZE=leak, but otherwise opt-in the "t4015-diff-whitespace.sh" test. The reason is that a18d66cefb9 "fixed" the leak in the preceding "no effect on diff" test, but for the first call to diff_words_flush() the "wol->buf" would be NULL, so we wouldn't double-free (and SANITIZE=address would see nothing amiss). With this change we'll still pass that test, showing that we've also fixed leaks on this codepath. We then have to skip the new "no effect on show" test because it happens to trip over an unrelated memory leak (in revision.c). The same goes for "move detection with submodules". Both of them pass with SANITIZE=address though, which would error on the "no effect on show" test before this change. Reported-by: Michael J Gruber <git@grubix.eu> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-17tests: demonstrate "show --word-diff --color-moved" regressionLibravatar Michael J Gruber1-1/+7
Add a failing test which demonstrates a regression in a18d66cefb ("diff.c: free "buf" in diff_words_flush()", 2022-03-04), the regression is discussed in detail in the subsequent commit. With it running `git show --word-diff --color-moved` with SANITIZE=address would emit: ==31191==ERROR: AddressSanitizer: attempting double-free on 0x617000021100 in thread T0: #0 0x49f0a2 in free (git+0x49f0a2) #1 0x9b0e4d in diff_words_flush diff.c:2153:3 #2 0x9aed5d in fn_out_consume diff.c:2354:3 #3 0xe092ab in consume_one xdiff-interface.c:43:9 #4 0xe072eb in xdiff_outf xdiff-interface.c:76:10 #5 0xec7014 in xdl_emit_diffrec xdiff/xutils.c:53:6 [...] 0x617000021100 is located 0 bytes inside of 768-byte region [0x617000021100,0x617000021400) freed by thread T0 here: #0 0x49f0a2 in free (git+0x49f0a2) [...(same stacktrace)...] previously allocated by thread T0 here: #0 0x49f603 in __interceptor_realloc (git+0x49f603) #1 0xde4da4 in xrealloc wrapper.c:126:8 #2 0x995dc5 in append_emitted_diff_symbol diff.c:794:2 #3 0x96c44a in emit_diff_symbol diff.c:1527:3 [...] This was not caught by the test suite because we test `diff --word-diff --color-moved` only so far. Therefore, add a test for `show`, too. Signed-off-by: Michael J Gruber <git@grubix.eu> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-17tests: use "test_hook" for misc "mkdir -p" and "chmod" casesLibravatar Ævar Arnfjörð Bjarmason5-78/+56
Make use of "test_hook" in various cases that didn't fit neatly into preceding commits. Here we need to indent blocks in addition to changing the test code, or to make other small cosmetic changes. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-17tests: change "mkdir -p && write_script" to use "test_hook"Libravatar Ævar Arnfjörð Bjarmason9-60/+27
Change tests that used a "mkdir -p .git/hooks && write_script" pattern to use the new "test_hook" helper instead. The new helper does not create the .git/hooks directory, rather we assume that the default template will do so for us. An upcoming series[1] will extend "test_hook" to operate in a "--template=" mode, but for now assuming that we have a .git/hooks already is a safe assumption. If that assumption becomes false in the future we'll only need to change 'test_hook", instead of all of these callsites. 1. https://lore.kernel.org/git/cover-00.13-00000000000-20211212T201308Z-avarab@gmail.com/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-17tests: change "cat && chmod +x" to use "test_hook"Libravatar Ævar Arnfjörð Bjarmason2-10/+10
Refactor various test code to use the "test_hook" helper. This change: - Fixes the long-standing issues with those tests using "#!/bin/sh" instead of "#!$SHELL_PATH". Using "#!/bin/sh" here happened to work because this code was so simple that it e.g. worked on Solaris /bin/sh. - Removes the "mkdir .git/hooks" invocation, as explained in a preceding commit we'll rely on the default templates to create that directory for us. For the test in "t5402-post-merge-hook.sh" it's easier and more correct to unroll the for-loop into a test_expect_success, so let's do that. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-17gc + p4 tests: use "test_hook", remove sub-shellsLibravatar Ævar Arnfjörð Bjarmason2-21/+24
Refactor the repository setup code for tests that test hooks the use of sub-shells when setting up the test repository and hooks, and use the "test_hook" wrapper instead of "write_scripts". Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>