summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-03-24Sync with 2.30.3Johannes Schindelin9-13/+237
* 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-24Git 2.30.3v2.30.3Johannes Schindelin3-2/+26
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2022-03-24Fix `GIT_CEILING_DIRECTORIES` with `C:\` and the likesJohannes Schindelin2-11/+23
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 outputÆvar Arnfjörð Bjarmason2-2/+28
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() APIÆvar Arnfjörð Bjarmason3-9/+50
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 optionVictoria Dye3-18/+4
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 optionVictoria Dye6-12/+2
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 refreshVictoria Dye3-39/+7
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-23The 14th batchJunio C Hamano1-0/+13
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-23Merge branch 'ab/plug-random-leaks'Junio C Hamano2-4/+19
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 'dc/complete-restore'Junio C Hamano1-0/+4
The command line completion support (in contrib/) learns to give modified paths to the "git restore" command. * dc/complete-restore: completion: tab completion of filenames for 'git restore'
2022-03-23Merge branch 'jc/cat-file-batch-default-format-optim'Junio C Hamano2-6/+35
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 'js/in-place-reverse-in-sequencer'Junio C Hamano1-6/+4
Code clean-up. * js/in-place-reverse-in-sequencer: sequencer: use reverse_commit_list() helper
2022-03-23Merge branch 'ac/test-lazy-fetch'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'Junio C Hamano3-4/+63
"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 'ds/doc-maintenance-synopsis-fix'Junio C Hamano1-18/+20
Doc update. * ds/doc-maintenance-synopsis-fix: maintenance: fix synopsis in documentation
2022-03-23Merge branch 'ab/reflog-prep-fix'Junio C Hamano2-0/+11
Regression fix. * ab/reflog-prep-fix: reflog: don't be noisy on empty reflogs
2022-03-23Merge branch 'ep/remove-duplicated-includes'Junio C Hamano6-6/+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'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'Junio C Hamano2-14/+175
"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'Junio C Hamano15-0/+167
A new built-in userdiff driver for kotlin. * jd/userdiff-kotlin: userdiff: add builtin diff driver for kotlin language.
2022-03-23Merge branch 'bc/block-sha1-without-gcc-asm-extension'Junio C Hamano1-17/+0
Get rid of one use of __asm__() GCC extension that does not help us much these days, which has an added advantage of not having to worry about -pedantic complaining. * bc/block-sha1-without-gcc-asm-extension: block-sha1: remove use of obsolete x86 assembly
2022-03-23Merge branch 'gc/submodule-update-part1'Junio C Hamano4-159/+183
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'Derrick Stolee2-7/+19
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'Derrick Stolee3-11/+10
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-23pack-objects: parse --filter directly into revs.filterDerrick Stolee1-6/+2
The previous change moved the 'revs' variable into cmd_pack_objects() and now we can remove the global filter_options in favor of revs.filter. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-23pack-objects: move revs out of get_object_list()Derrick Stolee1-15/+18
We intend to parse the --filter option directly into revs.filter, but we first need to move the 'revs' variable out of get_object_list() and pass it as a pointer instead. This change only deals with the issues of making that work. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-23list-objects-filter: remove CL_ARG__FILTERDerrick Stolee3-8/+5
We have established the command-line interface for the --[no-]filter options for a while now, so we do not need a helper to make this editable in the future. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-23git-prompt: put upstream comments togetherJustin Donnelly1-5/+5
Commit 6d158cba28 (bash completion: Support "divergence from upstream" messages in __git_ps1, 2010-06-17) introduced support for indicating divergence from upstream in the PS1 prompt. The comments at the top of git-prompt.sh that were introduced with that commit are several paragraphs long. Over the years, other comments have been inserted in between the paragraphs relating to divergence from upstream. This commit puts the comments relating to divergence from upstream back together. Signed-off-by: Justin Donnelly <justinrdonnelly@gmail.com> Reviewed-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-23git-prompt: make long upstream state indicator consistentJustin Donnelly1-5/+5
Use a pipe as a separator before long upstream state indicator. This is consistent with long state indicators for sparse and in-progress operations (e.g. merge). For comparison, `__git_ps1` examples without upstream state indicator: (main) (main %) (main *%) (main|SPARSE) (main %|SPARSE) (main *%|SPARSE) (main|SPARSE|REBASE 1/2) (main %|SPARSE|REBASE 1/2) Note that if there are long state indicators, they appear after short state indicators if there are any, or after the branch name if there are no short state indicators. Each long state indicator begins with a pipe (`|`) as a separator. Before/after examples with long upstream state indicator: | Before | After | | ------------------------------- | ------------------------------- | | (main u=) | (main|u=) | | (main u= origin/main) | (main|u= origin/main) | | (main u+1) | (main|u+1) | | (main u+1 origin/main) | (main|u+1 origin/main) | | (main % u=) | (main %|u=) | | (main % u= origin/main) | (main %|u= origin/main) | | (main % u+1) | (main %|u+1) | | (main % u+1 origin/main) | (main %|u+1 origin/main) | | (main|SPARSE u=) | (main|SPARSE|u=) | | (main|SPARSE u= origin/main) | (main|SPARSE|u= origin/main) | | (main|SPARSE u+1) | (main|SPARSE|u+1) | | (main|SPARSE u+1 origin/main) | (main|SPARSE|u+1 origin/main) | | (main %|SPARSE u=) | (main %|SPARSE|u=) | | (main %|SPARSE u= origin/main) | (main %|SPARSE|u= origin/main) | | (main %|SPARSE u+1) | (main %|SPARSE|u+1) | | (main %|SPARSE u+1 origin/main) | (main %|SPARSE|u+1 origin/main) | Signed-off-by: Justin Donnelly <justinrdonnelly@gmail.com> Reviewed-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-23git-prompt: make upstream state indicator location consistentJustin Donnelly1-12/+13
Make upstream state indicator location more consistent with similar state indicators (e.g. sparse). Group the short upstream state indicator (`=`, `<`, `>`, or `<>`) with other short state indicators immediately after the branch name. Previously short and long upstream state indicators appeared after all other state indicators. Use a separator (`SP` or `GIT_PS1_STATESEPARATOR`) between branch name and short upstream state indicator. Previously the short upstream state indicator would sometimes appear directly adjacent to the branch name instead of being separated. For comparison, `__git_ps1` examples without upstream state indicator: (main) (main %) (main *%) (main|SPARSE) (main %|SPARSE) (main *%|SPARSE) (main|SPARSE|REBASE 1/2) (main %|SPARSE|REBASE 1/2) Note that if there are short state indicators, they appear together after the branch name and separated from it by `SP` or `GIT_PS1_STATESEPARATOR`. Before/after examples with short upstream state indicator: | Before | After | | ---------------- | ---------------- | | (main=) | (main =) | | (main|SPARSE=) | (main =|SPARSE) | | (main %|SPARSE=) | (main %=|SPARSE) | Signed-off-by: Justin Donnelly <justinrdonnelly@gmail.com> Reviewed-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-23git-prompt: rename `upstream` to `upstream_type`Justin Donnelly1-13/+13
In `__git_ps1_show_upstream` rename the variable `upstream` to `upstream_type`. This allows `__git_ps1_show_upstream` to reference a variable named `upstream` that is declared `local` in `__git_ps1`, which calls `__git_ps1_show_upstream`. Signed-off-by: Justin Donnelly <justinrdonnelly@gmail.com> Reviewed-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-23hooks: fix "invoked hook" regression in a8cc5943338Ævar Arnfjörð Bjarmason1-0/+1
Fix a regression in a8cc5943338 (hooks: fix an obscure TOCTOU "did we just run a hook?" race, 2022-03-07): The "invoked_hook" variable passed to run_commit_hook() wasn't passed forward to run_hooks_opt(), as push_to_checkout() in that commit correctly did. Whether we ran the code contingent on having run the hook or not was thus undefined, but in practice on most (all?) modern platforms we'd have run it (almost?) all the time, since stack variables will get initialized to some random value, which most of the time isn't "0". This bug was revealed by running e.g. "t5537-fetch-shallow.sh" with the --valgrind option. Unfortunately running the whole test suite with --valgrind is really slow, so we didn't have a CI job that spotted this. The --valgrind output was: ==31275== Conditional jump or move depends on uninitialised value(s) ==31275== at 0x43C63F: prepare_to_commit (commit.c:1058) ==31275== by 0x4396A5: cmd_commit (commit.c:1722) ==31275== by 0x407C8A: run_builtin (git.c:465) ==31275== by 0x406741: handle_builtin (git.c:718) ==31275== by 0x407665: run_argv (git.c:785) ==31275== by 0x406500: cmd_main (git.c:916) ==31275== by 0x510839: main (common-main.c:56) ==31275== Uninitialised value was created by a stack allocation ==31275== at 0x43B344: prepare_to_commit (commit.c:719) Reported-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-23ls-tree: split up "fast path" callbacksÆvar Arnfjörð Bjarmason1-74/+125
Make the various if/else in the callbacks for the "fast path" a lot easier to read by just using common functions for the parts that are common, and have per-format callbacks for those parts that are different. 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: detect and error on --name-only --name-statusÆvar Arnfjörð Bjarmason2-7/+19
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: introduce "--format" optionÆvar Arnfjörð Bjarmason3-7/+272
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: support --object-only option for "git-ls-tree"Teng Long4-4/+36
'--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-23cocci: allow padding with `strbuf_addf()`Johannes Schindelin1-3/+3
A convenient way to pad strings is to use something like `strbuf_addf(&buf, "%20s", "Hello, world!")`. However, the Coccinelle rule that forbids a format `"%s"` with a constant string argument cast too wide a net, and also forbade such padding. The original rule was introduced by commit: 28c23cd4c39 (strbuf.cocci: suggest strbuf_addbuf() to add one strbuf to an other, 2019-01-25) Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Teng Long <dyroneteng@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-23ls-tree: introduce struct "show_tree_data"Ævar Arnfjörð Bjarmason1-15/+27
"show_tree_data" is a struct that packages the necessary fields for "show_tree()". This commit is a pre-prepared commit for supporting "--format" option and it does not affect any existing functionality. 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: slightly refactor `show_tree()`Teng Long1-37/+61
This is a non-functional change, we introduce an enum "ls_tree_cmdmode" then use it to mark which columns to output. This has the advantage of making the show_tree logic simpler and more readable, as well as making it easier to extend new options (for example, if we want to add a "--object-only" option, we just need to add a similar "short-circuit logic in "show_tree()"). 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: fix "--name-only" and "--long" combined use bugTeng Long2-6/+15
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: simplify nesting if/else logic in "show_tree()"Teng Long1-12/+9
Use the object_type() function to determine the object type from the "mode" passed to us by read_tree(), instead of doing so with the S_*() macros. Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Teng Long <dyronetengb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-23ls-tree: rename "retval" to "recurse" in "show_tree()"Teng Long1-4/+4
The variable which "show_tree()" return is named "retval", a name that's a little hard to understand. The commit rename "retval" to "recurse" which is a more meaningful name than before in the context. We do not need to take a look at "read_tree_at()" in "tree.c" to make sure what does "retval" mean. Signed-off-by: Teng Long <dyroneteng@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-23ls-tree: use "size_t", not "int" for "struct strbuf"'s "len"Ævar Arnfjörð Bjarmason1-3/+3
The "struct strbuf"'s "len" member is a "size_t", not an "int", so let's change our corresponding types accordingly. This also changes the "len" and "speclen" variables, which are likewise used to store the return value of strlen(), which returns "size_t", not "int". Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-23ls-tree: use "enum object_type", not {blob,tree,commit}_typeÆvar Arnfjörð Bjarmason1-6/+6
Change the ls-tree.c code to use type_name() on the enum instead of using the string constants. This doesn't matter either way for performance, but makes this a bit easier to read as we'll no longer need a strcmp() here. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-23ls-tree: add missing braces to "else" armsÆvar Arnfjörð Bjarmason1-2/+4
Add missing {} to the "else" arms in show_tree() per the CodingGuidelines. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-23ls-tree: remove commented-out codeÆvar Arnfjörð Bjarmason1-9/+0
Remove code added in f35a6d3bce7 (Teach core object handling functions about gitlinks, 2007-04-09), later patched in 7d0b18a4da1 (Add output flushing before fork(), 2008-08-04), and then finally ending up in its current form in d3bee161fef (tree.c: allow read_tree_recursive() to traverse gitlink entries, 2009-01-25). All while being commented-out! Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-23ls-tree tests: add tests for --name-statusÆvar Arnfjörð Bjarmason1-25/+28
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-21The thirteenth batchJunio C Hamano1-0/+15
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-21Merge branch 'jy/gitweb-no-need-for-meta'Junio C Hamano2-4/+15
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