summaryrefslogtreecommitdiff
path: root/builtin
AgeCommit message (Collapse)AuthorFilesLines
2022-03-21Merge branch 'ds/partial-bundles'Libravatar Junio C Hamano3-26/+25
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-16Merge branch 'ab/string-list-count-in-size-t'Libravatar Junio C Hamano4-11/+12
Count string_list items in size_t, not "unsigned int". * ab/string-list-count-in-size-t: string-list API: change "nr" and "alloc" to "size_t" gettext API users: don't explicitly cast ngettext()'s "n"
2022-03-16Merge branch 'ab/racy-hooks'Libravatar Junio C Hamano3-21/+33
Code clean-up to allow callers of run_commit_hook() to learn if it got "success" because the hook succeeded or because there wasn't any hook. * ab/racy-hooks: hooks: fix an obscure TOCTOU "did we just run a hook?" race merge: don't run post-hook logic on --no-verify
2022-03-16Merge branch 'jc/stash-drop'Libravatar Junio C Hamano2-465/+8
"git stash drop" is reimplemented as an internal call to reflog_delete() function, instead of invoking "git reflog delete" via run_command() API. * jc/stash-drop: stash: call reflog_delete() in reflog.c reflog: libify delete reflog function and helpers stash: add tests to ensure reflog --rewrite --updatref behavior
2022-03-16Merge branch 'tb/rename-remote-progress'Libravatar Junio C Hamano1-8/+31
"git remote rename A B", depending on the number of remote-tracking refs involved, takes long time renaming them. The command has been taught to show progress bar while making the user wait. * tb/rename-remote-progress: builtin/remote.c: show progress when renaming remote references builtin/remote.c: parse options in 'rename'
2022-03-16Merge branch 'vd/sparse-read-tree'Libravatar Junio C Hamano1-2/+12
"git read-tree" has been made to be aware of the sparse-index feature. * vd/sparse-read-tree: read-tree: make three-way merge sparse-aware read-tree: make two-way merge sparse-aware read-tree: narrow scope of index expansion for '--prefix' read-tree: integrate with sparse index read-tree: expand sparse checkout test coverage read-tree: explicitly disallow prefixes with a leading '/' status: fix nested sparse directory diff in sparse index sparse-index: prevent repo root from becoming sparse
2022-03-16Merge branch 'ab/object-file-api-updates'Libravatar Junio C Hamano15-37/+37
Object-file API shuffling. * ab/object-file-api-updates: object-file API: pass an enum to read_object_with_reference() object-file.c: add a literal version of write_object_file_prepare() object-file API: have hash_object_file() take "enum object_type" object API: rename hash_object_file_literally() to write_*() object-file API: split up and simplify check_object_signature() object API users + docs: check <0, not !0 with check_object_signature() object API docs: move check_object_signature() docs to cache.h object API: correct "buf" v.s. "map" mismatch in *.c and *.h object-file API: have write_object_file() take "enum object_type" object-file API: add a format_object_header() function object-file API: return "void", not "int" from hash_object_file() object-file.c: split up declaration of unrelated variables
2022-03-16Merge branch 'mf/fix-type-in-config-h'Libravatar Junio C Hamano1-1/+1
"git config -h" did not describe the "--type" option correctly. * mf/fix-type-in-config-h: config: correct "--type" option in "git config -h" output
2022-03-16Merge branch 'ps/fetch-mirror-optim'Libravatar Junio C Hamano2-18/+32
Various optimization for "git fetch". * ps/fetch-mirror-optim: refs/files-backend: optimize reading of symbolic refs remote: read symbolic refs via `refs_read_symbolic_ref()` refs: add ability for backends to special-case reading of symbolic refs fetch: avoid lookup of commits when not appending to FETCH_HEAD upload-pack: look up "want" lines via commit-graph
2022-03-13Merge branch 'ab/plug-random-leaks'Libravatar Junio C Hamano7-8/+19
Plug random memory leaks. * ab/plug-random-leaks: repository.c: free the "path cache" in repo_clear() range-diff: plug memory leak in read_patches() range-diff: plug memory leak in common invocation lockfile API users: simplify and don't leak "path" commit-graph: stop fill_oids_from_packs() progress on error and free() commit-graph: fix memory leak in misused string_list API submodule--helper: fix trivial leak in module_add() transport: stop needlessly copying bundle header references bundle: call strvec_clear() on allocated strvec remote-curl.c: free memory in cmd_main() urlmatch.c: add and use a *_release() function diff.c: free "buf" in diff_words_flush() merge-base: free() allocated "struct commit **" list index-pack: fix memory leaks
2022-03-13Merge branch 'gc/parse-tree-indirect-errors'Libravatar Junio C Hamano2-3/+12
Check the return value from parse_tree_indirect() to turn segfaults into calls to die(). * gc/parse-tree-indirect-errors: checkout, clone: die if tree cannot be parsed
2022-03-13Merge branch 'ps/fetch-atomic'Libravatar Junio C Hamano1-61/+129
"git fetch" can make two separate fetches, but ref updates coming from them were in two separate ref transactions under "--atomic", which has been corrected. * ps/fetch-atomic: fetch: make `--atomic` flag cover pruning of refs fetch: make `--atomic` flag cover backfilling of tags refs: add interface to iterate over queued transactional updates fetch: report errors when backfilling tags fails fetch: control lifecycle of FETCH_HEAD in a single place fetch: backfill tags before setting upstream fetch: increase test coverage of fetches
2022-03-09Merge branch 'ab/help-fixes'Libravatar Junio C Hamano1-10/+53
Updates to how command line options to "git help" are handled. * ab/help-fixes: help: don't print "\n" before single-section output help: add --no-[external-commands|aliases] for use with --all help: error if [-a|-g|-c] and [-i|-m|-w] are combined help: correct usage & behavior of "git help --all" help: note the option name on option incompatibility help.c: split up list_all_cmds_help() function help tests: test "git" and "git help [-a|-g] spacing help.c: use puts() instead of printf{,_ln}() for consistency help doc: add missing "]" to "[-a|--all]"
2022-03-09Merge branch 'jc/cat-file-batch-commands'Libravatar Junio C Hamano1-12/+166
"git cat-file" learns "--batch-command" mode, which is a more flexible interface than the existing "--batch" or "--batch-check" modes, to allow different kinds of inquiries made. * jc/cat-file-batch-commands: cat-file: add --batch-command mode cat-file: add remove_timestamp helper cat-file: introduce batch_mode enum to replace print_contents cat-file: rename cmdmode to transform_mode
2022-03-09clone: fail gracefully when cloning filtered bundleLibravatar Derrick Stolee1-0/+13
Users can create a new repository using 'git clone <bundle-file>'. The new "@filter" capability for bundles means that we can generate a bundle that does not contain all reachable objects, even if the header has no negative commit OIDs. It is feasible to think that we could make a filtered bundle work with the command git clone --filter=$filter --bare <bundle-file> or possibly replacing --bare with --no-checkout. However, this requires having some repository-global config that specifies the specified object filter and notifies Git about the existence of promisor pack-files. Without a remote, that is currently impossible. As a stop-gap, parse the bundle header during 'git clone' and die() with a helpful error message instead of the current behavior of failing due to "missing objects". Most of the existing logic for handling bundle clones actually happens in fetch-pack.c, but that logic is the same as if the user specified 'git fetch <bundle>', so we want to avoid failing to fetch a filtered bundle when in an existing repository that has the proper config set up for at least one remote. Carefully comment around the test that this is not the desired long-term behavior of 'git clone' in this case, but instead that we need to do more work before that is possible. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-09rev-list: move --filter parsing into revision.cLibravatar Derrick Stolee1-11/+0
Now that 'struct rev_info' has a 'filter' member and most consumers of object filtering are using that member instead of an external struct, move the parsing of the '--filter' option out of builtin/rev-list.c and into revision.c. This use within handle_revision_pseudo_opt() allows us to find the option within setup_revisions() if the arguments are passed directly. In the case of a command such as 'git blame', the arguments are first scanned and checked with parse_revision_opt(), which complains about the option, so 'git blame --filter=blob:none <file>' does not become valid with this change. Some commands, such as 'git diff' gain this option without having it make an effect. And 'git diff --objects' was already possible, but does not actually make sense in that builtin. The key addition that is coming is 'git bundle create --filter=<X>' so we can create bundles containing promisor packs. More work is required to make them fully functional, but that will follow. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-09list-objects: consolidate traverse_commit_list[_filtered]Libravatar Derrick Stolee2-4/+4
Now that all consumers of traverse_commit_list_filtered() populate the 'filter' member of 'struct rev_info', we can drop that parameter from the method prototype to simplify things. In addition, the only thing different now between traverse_commit_list_filtered() and traverse_commit_list() is the presence of the 'omitted' parameter, which is only non-NULL for one caller. We can consolidate these two methods by having one call the other and use the simpler form everywhere the 'omitted' parameter would be NULL. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-09pack-bitmap: drop filter in prepare_bitmap_walk()Libravatar Derrick Stolee2-6/+4
Now that all consumers of prepare_bitmap_walk() have populated the 'filter' member of 'struct rev_info', we can drop that extra parameter from the method and access it directly from the 'struct rev_info'. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-09pack-objects: use rev.filter when possibleLibravatar Derrick Stolee1-2/+3
In builtin/pack-objects.c, we use a 'filter_options' global to populate the --filter=<X> argument. The previous change created a pointer to a filter option in 'struct rev_info', so we can use that pointer here as a start to simplifying some usage of object filters. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-09revision: put object filter into struct rev_infoLibravatar Derrick Stolee1-14/+12
Placing a 'struct list_objects_filter_options' within 'struct rev_info' will assist making some bookkeeping around object filters in the future. For now, let's use this new member to remove a static global instance of the struct from builtin/rev-list.c. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-07hooks: fix an obscure TOCTOU "did we just run a hook?" raceLibravatar Ævar Arnfjörð Bjarmason3-14/+23
Fix a Time-of-check to time-of-use (TOCTOU) race in code added in 680ee550d72 (commit: skip discarding the index if there is no pre-commit hook, 2017-08-14). This obscure race condition can occur if we e.g. ran the "pre-commit" hook and it modified the index, but hook_exists() returns false later on (e.g., because the hook itself went away, the directory became unreadable, etc.). Then we won't call discard_cache() when we should have. The race condition itself probably doesn't matter, and users would have been unlikely to run into it in practice. This problem has been noted on-list when 680ee550d72 was discussed[1], but had not been fixed. This change is mainly intended to improve the readability of the code involved, and to make reasoning about it more straightforward. It wasn't as obvious what we were trying to do here, but by having an "invoked_hook" it's clearer that e.g. our discard_cache() is happening because of the earlier hook execution. Let's also change this for the push-to-checkout hook. Now instead of checking if the hook exists and either doing a push to checkout or a push to deploy we'll always attempt a push to checkout. If the hook doesn't exist we'll fall back on push to deploy. The same behavior as before, without the TOCTOU race. See 0855331941b (receive-pack: support push-to-checkout hook, 2014-12-01) for the introduction of the previous behavior. This leaves uses of hook_exists() in two places that matter. The "reference-transaction" check in refs.c, see 67541597670 (refs: implement reference transaction hook, 2020-06-19), and the "prepare-commit-msg" hook, see 66618a50f9c (sequencer: run 'prepare-commit-msg' hook, 2018-01-24). In both of those cases we're saving ourselves CPU time by not preparing data for the hook that we'll then do nothing with if we don't have the hook. So using this "invoked_hook" pattern doesn't make sense in those cases. The "reference-transaction" and "prepare-commit-msg" hook also aren't racy. In those cases we'll skip the hook runs if we race with a new hook being added, whereas in the TOCTOU races being fixed here we were incorrectly skipping the required post-hook logic. 1. https://lore.kernel.org/git/20170810191613.kpmhzg4seyxy3cpq@sigill.intra.peff.net/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-07merge: don't run post-hook logic on --no-verifyLibravatar Ævar Arnfjörð Bjarmason1-9/+12
Fix a minor bug introduced in bc40ce4de61 (merge: --no-verify to bypass pre-merge-commit hook, 2019-08-07), when that change made the --no-verify option bypass the "pre-merge-commit" hook it didn't update the corresponding find_hook() (later hook_exists()) condition. As can be seen in the preceding commit in 6098817fd7f (git-merge: honor pre-merge-commit hook, 2019-08-07) the two should go hand in hand. There's no point in invoking discard_cache() here if the hook couldn't have possibly updated the index. It's buggy that we use "hook_exist()" here, and as discussed in the subsequent commit it's subject to obscure race conditions that we're about to fix, but for now this change is a strict improvement that retains any caveats to do with the use of "hooks_exist()" as-is. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-07string-list API: change "nr" and "alloc" to "size_t"Libravatar Ævar Arnfjörð Bjarmason2-9/+10
Change the "nr" and "alloc" members of "struct string_list" to use "size_t" instead of "nr". On some platforms the size of an "unsigned int" will be smaller than a "size_t", e.g. a 32 bit unsigned v.s. 64 bit unsigned. As "struct string_list" is a generic API we use in a lot of places this might cause overflows. As one example: code in "refs.c" keeps track of the number of refs with a "size_t", and auxiliary code in builtin/remote.c in get_ref_states() appends those to a "struct string_list". While we're at it split the "nr" and "alloc" in string-list.h across two lines, which is the case for most such struct member declarations (e.g. in "strbuf.h" and "strvec.h"). Changing e.g. "int i" to "size_t i" in run_and_feed_hook() isn't strictly necessary, and there are a lot more cases where we'll use a local "int", "unsigned int" etc. variable derived from the "nr" in the "struct string_list". But in that case as well as add_wrapped_shortlog_msg() in builtin/shortlog.c we need to adjust the printf format referring to "nr" anyway, so let's also change the other variables referring to it. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-07gettext API users: don't explicitly cast ngettext()'s "n"Libravatar Ævar Arnfjörð Bjarmason2-2/+2
Change a few stray users of the inline gettext.h Q_() function to stop casting its "n" argument, the vast majority of the users of that wrapper API use the implicit cast to "unsigned long". The ngettext() function (which Q_() resolves to) takes an "unsigned long int", and so does our Q_() wrapper for it, see 0c9ea33b90f (i18n: add stub Q_() wrapper for ngettext, 2011-03-09). The function isn't ours, but provided by e.g. GNU libintl. This amends code added in added in 7171a0b0cf5 (index-pack: correct "len" type in unpack_data(), 2016-07-13). The cast it added for the printf format to die() was needed, but not the cast to Q_(). Likewise the casts in strbuf.c added in 8f354a1faed (l10n: localizable upload progress messages, 2019-07-02) and for builtin/merge-recursive.c in ccf7813139f (i18n: merge-recursive: mark error messages for translation, 2016-09-15) weren't needed. In the latter case the cast was copy/pasted from the argument to warning() itself, added in b74d779bd90 (MinGW: Fix compiler warning in merge-recursive, 2009-05-23). The cast for warning() is needed, but not the one for ngettext()'s "n" argument. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-06Merge branch 'jt/ls-files-stage-recurse'Libravatar Junio C Hamano1-2/+2
Many output modes of "ls-files" do not work with its "--recurse-submodules" option, but the "-s" mode has been taught to work with it. * jt/ls-files-stage-recurse: ls-files: support --recurse-submodules --stage
2022-03-06Merge branch 'gc/stash-on-branch-with-multi-level-name'Libravatar Junio C Hamano1-1/+1
"git checkout -b branch/with/multi/level/name && git stash" only recorded the last level component of the branch name, which has been corrected. * gc/stash-on-branch-with-multi-level-name: stash: strip "refs/heads/" with skip_prefix
2022-03-06Merge branch 'ah/advice-switch-requires-detach-to-detach'Libravatar Junio C Hamano1-11/+19
The error message given by "git switch HEAD~4" has been clarified to suggest the "--detach" option that is required. * ah/advice-switch-requires-detach-to-detach: switch: mention the --detach option when dying due to lack of a branch
2022-03-06Merge branch 'ab/c99-designated-initializers'Libravatar Junio C Hamano1-4/+10
Use designated initializers we started using in mid 2017 in more parts of the codebase that are relatively quiescent. * ab/c99-designated-initializers: fast-import.c: use designated initializers for "partial" struct assignments refspec.c: use designated initializers for "struct refspec_item" convert.c: use designated initializers for "struct stream_filter*" userdiff.c: use designated initializers for "struct userdiff_driver" archive-*.c: use designated initializers for "struct archiver" object-file: use designated initializers for "struct git_hash_algo" trace2: use designated initializers for "struct tr2_dst" trace2: use designated initializers for "struct tr2_tgt" imap-send.c: use designated initializers for "struct imap_server_conf"
2022-03-06Merge branch 'mc/index-pack-report-max-size'Libravatar Junio C Hamano1-2/+6
When "index-pack" dies due to incoming data exceeding the maximum allowed input size, include the value of the limit in the error message. * mc/index-pack-report-max-size: index-pack: clarify the breached limit
2022-03-06Merge branch 'ac/usage-string-fixups'Libravatar Junio C Hamano3-5/+5
Usage-string normalization. * ac/usage-string-fixups: amend remaining usage strings according to style guide
2022-03-06Merge branch 'ds/worktree-docs'Libravatar Junio C Hamano1-63/+75
Tighten the language around "working tree" and "worktree" in the docs. * ds/worktree-docs: worktree: use 'worktree' over 'working tree' worktree: use 'worktree' over 'working tree' worktree: use 'worktree' over 'working tree' worktree: use 'worktree' over 'working tree' worktree: use 'worktree' over 'working tree' worktree: use 'worktree' over 'working tree' worktree: use 'worktree' over 'working tree' worktree: extract checkout_worktree() worktree: extract copy_sparse_checkout() worktree: extract copy_filtered_worktree_config() worktree: combine two translatable messages
2022-03-06Merge branch 'rs/bisect-executable-not-found'Libravatar Junio C Hamano1-13/+74
A not-so-common mistake is to write a script to feed "git bisect run" without making it executable, in which case all tests will exit with 126 or 127 error codes, even on revisions that are marked as good. Try to recognize this situation and stop iteration early. * rs/bisect-executable-not-found: bisect--helper: double-check run command on exit code 126 and 127 bisect: document run behavior with exit codes 126 and 127 bisect--helper: release strbuf and strvec on run error bisect--helper: report actual bisect_state() argument on error
2022-03-06Merge branch 'en/sparse-checkout-fixes'Libravatar Junio C Hamano1-5/+73
Further polishing of "git sparse-checkout". * en/sparse-checkout-fixes: sparse-checkout: reject arguments in cone-mode that look like patterns sparse-checkout: error or warn when given individual files sparse-checkout: pay attention to prefix for {set, add} sparse-checkout: correctly set non-cone mode when expected sparse-checkout: correct reapply's handling of options
2022-03-04lockfile API users: simplify and don't leak "path"Libravatar Ævar Arnfjörð Bjarmason1-2/+1
Fix a memory leak in code added in 6c622f9f0bb (commit-graph: write commit-graph chains, 2019-06-18). We needed to free the "lock_name" if we encounter errors, and the "graph_name" after we'd run unlink() on it. For the case of write_commit_graph_file() refactoring the code to free the "lock_name" after we were done using the "struct lock_file lk" would have made the control flow more complex. Luckily we can free the "lock_file" right after the hold_lock_file_for_update() call, if it makes use of "path" at all it'll have copied its contents to a "struct strbuf" of its own. While I'm at it let's fix code added in fb10ca5b543 (sparse-checkout: write using lockfile, 2019-11-21) in write_patterns_and_update() to avoid the same complexity that I thought I needed when I wrote the initial fix for write_commit_graph_file(). We can free the "sparse_filename" right after calling hold_lock_file_for_update(), we don't need to wait until we're exiting the function to do so. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-04commit-graph: fix memory leak in misused string_list APILibravatar Ævar Arnfjörð Bjarmason1-3/+3
When this code was migrated to the string_list API in d88b14b3fd6 (commit-graph: use string-list API for input, 2018-06-27) it was made to use used both STRING_LIST_INIT_NODUP and a strbuf_detach() pattern. Those should not be used together if string_list_clear() is expected to free the memory, instead we need to either use STRING_LIST_INIT_DUP with a string_list_append_nodup(), or a STRING_LIST_INIT_NODUP and manually fiddle with the "strdup_strings" member before calling string_list_clear(). Let's do the former. Since "strdup_strings = 1" is set now other code might be broken by relying on "pack_indexes" not to duplicate it strings, but that doesn't happen. When we pass this down to write_commit_graph() that code uses the "struct string_list" without modifying it. Let's add a "const" to the variable to have the compiler enforce that assumption. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-04submodule--helper: fix trivial leak in module_add()Libravatar Ævar Arnfjörð Bjarmason1-1/+4
Fix a memory leak in code added in a6226fd772b (submodule--helper: convert the bulk of cmd_add() to C, 2021-08-10). If "realrepo" isn't a copy of the "repo" member we should free() it. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-04bundle: call strvec_clear() on allocated strvecLibravatar Ævar Arnfjörð Bjarmason1-0/+1
Fixing this small memory leak in cmd_bundle_create() gets "t5607-clone-bundle.sh" closer to passing under SANITIZE=leak. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-04urlmatch.c: add and use a *_release() functionLibravatar Ævar Arnfjörð Bjarmason1-1/+1
Plug a memory leak in credential_apply_config() by adding and using a new urlmatch_config_release() function. This just does a string_list_clear() on the "vars" member. This finished up work on normalizing the init/free pattern in this API, started in 73ee449bbf2 (urlmatch.[ch]: add and use URLMATCH_CONFIG_INIT, 2021-10-01). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-04merge-base: free() allocated "struct commit **" listLibravatar Ævar Arnfjörð Bjarmason1-1/+4
Fix a memory leak in 53eda89b2fe (merge-base: teach "git merge-base" to drive underlying merge_bases_many(), 2008-07-30) by calling free() on the "struct commit **" list used by "git merge-base". This gets e.g. "t6010-merge-base.sh" closer to passing under SANITIZE=leak, it failed 8 tests before when compiled with that option, and now fails only 5 tests. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-04index-pack: fix memory leaksLibravatar Ævar Arnfjörð Bjarmason1-0/+5
Fix various memory leaks in "git index-pack", due to how tightly coupled this command is with the revision walking this doesn't make any new tests pass. But e.g. this now passes, and had several failures before, i.e. we still have failures in tests 3, 5 etc., which are being skipped here. ./t5300-pack-object.sh --run=1-2,4,6-27,30-42 It is a bit odd that we'll free "opts.anomaly", since the "opts" is a "struct pack_idx_option" declared in pack.h. In pack-write.c there's a reset_pack_idx_option(), but it only wipes the contents, but doesn't free() anything. Doing this here in cmd_index_pack() is correct because while the struct is declared in pack.h, this code in builtin/index-pack.c (in read_v2_anomalous_offsets()) is what allocates the "opts.anomaly", so we should also free it here. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-03config: correct "--type" option in "git config -h" outputLibravatar Matheus Felipe1-1/+1
The usage help for --type option of `git config` is missing `type` in the argument placeholder (`<>`). Add it. Signed-off-by: Matheus Felipe <matheusfelipeog@protonmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-03builtin/remote.c: show progress when renaming remote referencesLibravatar Taylor Blau1-5/+25
When renaming a remote, Git needs to rename all remote tracking references to the remote's new name (e.g., renaming "refs/remotes/old/foo" to "refs/remotes/new/foo" when renaming a remote from "old" to "new"). This can be somewhat slow when there are many references to rename, since each rename is done in a separate call to rename_ref() as opposed to grouping all renames together into the same transaction. It would be nice to execute all renames as a single transaction, but there is a snag: the reference transaction backend doesn't support renames during a transaction (only individually, via rename_ref()). The reasons there are described in more detail in [1], but the main problem is that in order to preserve the existing reflog, it must be moved while holding both locks (i.e., on "oldname" and "newname"), and the ref transaction code doesn't support inserting arbitrary actions into the middle of a transaction like that. As an aside, adding support for this to the ref transaction code is less straightforward than inserting both a ref_update() and ref_delete() call into the same transaction. rename_ref()'s special handling to detect D/F conflicts would need to be rewritten for the transaction code if we wanted to proactively catch D/F conflicts when renaming a reference during a transaction. The reftable backend could support this much more readily because of its lack of D/F conflicts. Instead of a more complex modification to the ref transaction code, display a progress meter when running verbosely in order to convince the user that Git is doing work while renaming a remote. This is mostly done as-expected, with the minor caveat that we intentionally count symrefs renames twice, since renaming a symref takes place over two separate calls (one to delete the old one, and another to create the new one). [1]: https://lore.kernel.org/git/572367B4.4050207@alum.mit.edu/ Suggested-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-03builtin/remote.c: parse options in 'rename'Libravatar Taylor Blau1-3/+6
The 'git remote rename' command doesn't currently take any command-line arguments besides the existing and new name of a remote, and so has no need to call parse_options(). But the subsequent patch will add a `--[no-]progress` option, in which case we will need to call parse_options(). Do so now so as to avoid cluttering the following patch with noise, like adjusting setting `rename.{old,new}_name` to argv[0] and argv[1], since parse_options handles advancing argv past the name of the sub-command. Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-02stash: call reflog_delete() in reflog.cLibravatar John Cai1-14/+4
Now that cmd_reflog_delete has been libified an exported it into a new reflog.c library so we can call it directly from builtin/stash.c. This not only gives us a performance gain since we don't need to create a subprocess, but it also allows us to use the ref transactions api in the future. Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: John Cai <johncai86@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-02reflog: libify delete reflog function and helpersLibravatar John Cai1-451/+4
Currently stash shells out to reflog in order to delete refs. In an effort to reduce how much we shell out to a subprocess, libify the functionality that stash needs into reflog.c. Add a reflog_delete function that is pretty much the logic in the while loop in builtin/reflog.c cmd_reflog_delete(). This is a function that builtin/reflog.c and builtin/stash.c can both call. Also move functions needed by reflog_delete and export them. Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: John Cai <johncai86@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-01checkout, clone: die if tree cannot be parsedLibravatar Glen Choo2-3/+12
When a tree oid is invalid, parse_tree_indirect() can return NULL. Check for NULL instead of proceeding as though it were a valid pointer and segfaulting. Signed-off-by: Glen Choo <chooglen@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-01read-tree: make three-way merge sparse-awareLibravatar Victoria Dye1-5/+0
Enable use of 'merged_sparse_dir' in 'threeway_merge'. As with two-way merge, the contents of each conflicted sparse directory are merged without referencing the index, avoiding sparse index expansion. As with two-way merge, the 't/t1092-sparse-checkout-compatibility.sh' test 'read-tree --merge with edit/edit conflicts in sparse directories' confirms that three-way merges with edit/edit changes (both with and without conflicts) inside a sparse directory result in the correct index state or error message. To ensure the index is not unnecessarily expanded, add three-way merge cases to 'sparse index is not expanded: read-tree'. Signed-off-by: Victoria Dye <vdye@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-01read-tree: make two-way merge sparse-awareLibravatar Victoria Dye1-5/+0
Enable two-way merge with 'git read-tree' without expanding the sparse index. When in a sparse index, a two-way merge will trivially succeed as long as there are not changes to the same sparse directory in multiple trees (i.e., sparse directory-level "edit-edit" conflicts). If there are such conflicts, the merge will fail despite the possibility that individual files could merge cleanly. In order to resolve these "edit-edit" conflicts, "conflicted" sparse directories are - rather than rejected - merged by traversing their associated trees by OID. For each child of the sparse directory: 1. Files are merged as normal (see Documentation/git-read-tree.txt for details). 2. Subdirectories are treated as sparse directories and merged in 'twoway_merge'. If there are no conflicts, they are merged according to the rules in Documentation/git-read-tree.txt; otherwise, the subdirectory is recursively traversed and merged. This process allows sparse directories to be individually merged at the necessary depth *without* expanding a full index. The 't/t1092-sparse-checkout-compatibility.sh' test 'read-tree --merge with edit/edit conflicts in sparse directories' tests two-way merges with 1) changes inside sparse directories that do not conflict and 2) changes that do conflict (with the correct file(s) reported in the error message). Additionally, add two-way merge cases to 'sparse index is not expanded: read-tree' to confirm that the index is not expanded regardless of whether edit/edit conflicts are present in a sparse directory. Signed-off-by: Victoria Dye <vdye@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-01read-tree: narrow scope of index expansion for '--prefix'Libravatar Victoria Dye1-2/+1
When 'git read-tree' is provided with a prefix, expand the index only if the prefix is equivalent to a sparse directory or contained within one. If the index is not expanded in these cases, 'ce_in_traverse_path' will indicate that the relevant sparse directory is not in the prefix/traverse path, skipping past it and not unpacking the appropriate tree(s). If the prefix is in-cone, its sparse subdirectories (if any) will be traversed correctly without index expansion. The behavior of 'git read-tree' with prefixes 1) inside of cone, 2) equal to a sparse directory, and 3) inside a sparse directory are all tested as part of the 't/t1092-sparse-checkout-compatibility.sh' test 'read-tree --prefix', ensuring that the sparse index case works the way it did prior to this change as well as matching non-sparse index sparse-checkout. Helped-by: Elijah Newren <newren@gmail.com> Signed-off-by: Victoria Dye <vdye@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-01read-tree: integrate with sparse indexLibravatar Victoria Dye1-2/+19
Enable use of sparse index in 'git read-tree'. The integration in this patch is limited only to usage of 'read-tree' that does not need additional functional changes for the sparse index to behave as expected (i.e., produce the same user-facing results as a non-sparse index sparse-checkout). To ensure no unexpected behavior occurs, the index is explicitly expanded when: * '--no-sparse-checkout' is specified (because it disables sparse-checkout) * '--prefix' is specified (if the prefix is inside a sparse directory, the prefixed tree cannot be properly traversed) * two or more <tree-ish> arguments are specified ('twoway_merge' and 'threeway_merge' do not yet support merging sparse directories) Signed-off-by: Victoria Dye <vdye@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>