summaryrefslogtreecommitdiff
path: root/builtin
AgeCommit message (Collapse)AuthorFilesLines
2022-02-01branch: move --set-upstream-to behavior to dwim_and_setup_tracking()Libravatar Glen Choo1-6/+3
This commit is preparation for a future commit that will simplify create_branch() so that it always creates a branch. This will allow create_branch() to accept a dry_run parameter (which is needed for "git branch --recurse-submodules"). create_branch() used to always create a branch, but 4fc5006676 (Add branch --set-upstream, 2010-01-18) changed it to also be able to set tracking information without creating a branch. Refactor the code that sets tracking information into its own functions dwim_branch_start() and dwim_and_setup_tracking(). Also change an invocation of create_branch() in cmd_branch() in builtin/branch.c to use dwim_and_setup_tracking(), since that invocation is only for setting tracking information (in "git branch --set-upstream-to"). As of this commit, create_branch() is no longer invoked in a way that does not create branches. Helped-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Glen Choo <chooglen@google.com> Reviewed-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-31Merge branch 'js/branch-track-inherit' into gc/branch-recurse-submodulesLibravatar Junio C Hamano2-4/+8
* js/branch-track-inherit: branch,checkout: fix --track documentation branch,checkout: fix --track usage strings config: require lowercase for branch.*.autosetupmerge branch: add flags and config to inherit tracking branch: accept multiple upstream branches for tracking
2022-01-20branch,checkout: fix --track documentationLibravatar René Scharfe2-2/+2
Document that the accepted variants of the --track option are --track, --track=direct, and --track=inherit. The equal sign in the latter two cannot be replaced with whitespace; in general optional arguments need to be attached firmly to their option. Put "direct" consistently before "inherit", if only for the reasons that the former is the default, explained first in the documentation, and comes before the latter alphabetically. Mention both modes in the short help so that readers don't have to look them up in the full documentation. They are literal strings and thus untranslatable. PARSE_OPT_LITERAL_ARGHELP is inferred due to the pipe and parenthesis characters, so we don't have to provide that flag explicitly. Mention that -t has the same effect as --track and --track=direct. There is no way to specify inherit mode using the short option, because short options generally don't accept optional arguments. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-18branch,checkout: fix --track usage stringsLibravatar Josh Steadmon2-5/+5
As Ævar pointed out in [1], the use of PARSE_OPT_LITERAL_ARGHELP with a list of allowed parameters is not recommended. Both git-branch and git-checkout were changed in d311566 (branch: add flags and config to inherit tracking, 2021-12-20) to use this discouraged combination for their --track flags. Fix this by removing PARSE_OPT_LITERAL_ARGHELP, and changing the arghelp to simply be "mode". Users may discover allowed values in the manual pages. [1]: https://lore.kernel.org/git/220111.86a6g3yqf9.gmgdl@evledraar.gmail.com/ Signed-off-by: Josh Steadmon <steadmon@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-20branch: add flags and config to inherit trackingLibravatar Josh Steadmon2-4/+8
It can be helpful when creating a new branch to use the existing tracking configuration from the branch point. However, there is currently not a method to automatically do so. Teach git-{branch,checkout,switch} an "inherit" argument to the "--track" option. When this is set, creating a new branch will cause the tracking configuration to default to the configuration of the branch point, if set. For example, if branch "main" tracks "origin/main", and we run `git checkout --track=inherit -b feature main`, then branch "feature" will track "origin/main". Thus, `git status` will show us how far ahead/behind we are from origin, and `git pull` will pull from origin. This is particularly useful when creating branches across many submodules, such as with `git submodule foreach ...` (or if running with a patch such as [1], which we use at $job), as it avoids having to manually set tracking info for each submodule. Since we've added an argument to "--track", also add "--track=direct" as another way to explicitly get the original "--track" behavior ("--track" without an argument still works as well). Finally, teach branch.autoSetupMerge a new "inherit" option. When this is set, "--track=inherit" becomes the default behavior. [1]: https://lore.kernel.org/git/20180927221603.148025-1-sbeller@google.com/ Signed-off-by: Josh Steadmon <steadmon@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-29Merge branch 'tb/plug-pack-bitmap-leaks'Libravatar Junio C Hamano3-5/+14
Leakfix. * tb/plug-pack-bitmap-leaks: pack-bitmap.c: more aggressively free in free_bitmap_index() pack-bitmap.c: don't leak type-level bitmaps midx.c: write MIDX filenames to strbuf builtin/multi-pack-index.c: don't leak concatenated options builtin/repack.c: avoid leaking child arguments builtin/pack-objects.c: don't leak memory via arguments t/helper/test-read-midx.c: free MIDX within read_midx_file() midx.c: don't leak MIDX from verify_midx_file midx.c: clean up chunkfile after reading the MIDX
2021-11-29Merge branch 'jc/fix-ref-sorting-parse'Libravatar Junio C Hamano4-23/+24
Things like "git -c branch.sort=bogus branch new HEAD", i.e. the operation modes of the "git branch" command that do not need the sort key information, no longer errors out by seeing a bogus sort key. * jc/fix-ref-sorting-parse: for-each-ref: delay parsing of --sort=<atom> options
2021-11-29Merge branch 'so/stash-staged'Libravatar Junio C Hamano1-9/+71
"git stash" learned the "--staged" option to stash away what has been added to the index (and nothing else). * so/stash-staged: stash: get rid of unused argument in stash_staged() stash: implement '--staged' option for 'push' and 'save'
2021-11-21Merge branch 'ev/pull-already-up-to-date-is-noop'Libravatar Junio C Hamano1-2/+4
"git pull" with any strategy when the other side is behind us should succeed as it is a no-op, but doesn't. * ev/pull-already-up-to-date-is-noop: pull: should be noop when already-up-to-date
2021-11-18pull: should be noop when already-up-to-dateLibravatar Erwin Villejo1-2/+4
The already-up-to-date pull bug was fixed for --ff-only but it did not include the case where --ff or --ff-only are not specified. This updates the --ff-only fix to include the case where --ff or --ff-only are not specified in command line flags or config. Signed-off-by: Erwin Villejo <erwin.villejo@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-12Merge branch 'ab/fsck-unexpected-type'Libravatar Junio C Hamano1-1/+2
Regression fix. * ab/fsck-unexpected-type: object-file: free(*contents) only in read_loose_object() caller object-file: fix SEGV on free() regression in v2.34.0-rc2
2021-11-11object-file: free(*contents) only in read_loose_object() callerLibravatar Ævar Arnfjörð Bjarmason1-1/+2
In the preceding commit a free() of uninitialized memory regression in 96e41f58fe1 (fsck: report invalid object type-path combinations, 2021-10-01) was fixed, but we'd still have an issue with leaking memory from fsck_loose(). Let's fix that issue too. That issue was introduced in my 31deb28f5e0 (fsck: don't hard die on invalid object types, 2021-10-01). It can be reproduced under SANITIZE=leak with the test I added in 093fffdfbec (fsck tests: add test for fsck-ing an unknown type, 2021-10-01): ./t1450-fsck.sh --run=84 -vixd In some sense it's not a problem, we lost the same amount of memory in terms of things malloc'd and not free'd. It just moved from the "still reachable" to "definitely lost" column in valgrind(1) nomenclature[1], since we'd have die()'d before. But now that we don't hard die() anymore in the library let's properly free() it. Doing so makes this code much easier to follow, since we'll now have one function owning the freeing of the "contents" variable, not two. For context on that memory management pattern the read_loose_object() function was added in f6371f92104 (sha1_file: add read_loose_object() function, 2017-01-13) and subsequently used in c68b489e564 (fsck: parse loose object paths directly, 2017-01-13). The pattern of it being the task of both sides to free() the memory has been there in this form since its inception. 1. https://valgrind.org/docs/manual/mc-manual.html#mc-manual.leaks Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-10Merge branch 'ds/no-usable-cron-on-macos'Libravatar Junio C Hamano1-6/+21
"git maintenance run" learned to use system supplied scheduler backend, but cron on macOS turns out to be unusable for this purpose. * ds/no-usable-cron-on-macos: maintenance: disable cron on macOS
2021-11-10Merge branch 'jc/fix-pull-ff-only-when-already-up-to-date'Libravatar Junio C Hamano1-1/+28
"git pull --ff-only" and "git pull --rebase --ff-only" should make it a no-op to attempt pulling from a remote that is behind us, but instead the command errored out by saying it was impossible to fast-forward, which may technically be true, but not a useful thing to diagnose as an error. This has been corrected. * jc/fix-pull-ff-only-when-already-up-to-date: pull: --ff-only should make it a noop when already-up-to-date
2021-11-10maintenance: disable cron on macOSLibravatar Derrick Stolee1-6/+21
In eba1ba9 (maintenance: `git maintenance run` learned `--scheduler=<scheduler>`, 2021-09-04), we introduced the ability to specify a scheduler explicitly. This led to some extra checks around whether an alternative scheduler was available. This added the functionality of removing background maintenance from schedulers other than the one selected. On macOS, cron is technically available, but running 'crontab' triggers a UI prompt asking for special permissions. This is the major reason why launchctl is used as the default scheduler. The is_crontab_available() method triggers this UI prompt, causing user disruption. Remove this disruption by using an #ifdef to prevent running crontab this way on macOS. This has the unfortunate downside that if a user manually selects cron via the '--scheduler' option, then adjusting the scheduler later will not remove the schedule from cron. The '--scheduler' option ignores the is_available checks, which is how we can get into this situation. Extract the new check_crontab_process() method to avoid making the 'child' variable unused on macOS. The method is marked MAYBE_UNUSED because it has no callers on macOS. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-04Merge branch 'ar/fix-git-pull-no-verify'Libravatar Junio C Hamano1-0/+6
"git pull --no-verify" did not affect the underlying "git merge". * ar/fix-git-pull-no-verify: pull: honor --no-verify and do not call the commit-msg hook
2021-11-03Merge branch 'jx/message-fixes'Libravatar Junio C Hamano1-1/+1
Fixes to recently added messages. * jx/message-fixes: i18n: fix typos found during l10n for git 2.34.0
2021-11-01Merge branch 'gc/use-repo-settings'Libravatar Junio C Hamano2-5/+5
It is wrong to read some settings directly from the config subsystem, as things like feature.experimental can affect their default values. * gc/use-repo-settings: gc: perform incremental repack when implictly enabled fsck: verify multi-pack-index when implictly enabled fsck: verify commit graph when implicitly enabled
2021-11-01Merge branch 'ab/ignore-replace-while-working-on-commit-graph'Libravatar Junio C Hamano1-1/+1
Teach "git commit-graph" command not to allow using replace objects at all, as we do not use the commit-graph at runtime when we see object replacement. * ab/ignore-replace-while-working-on-commit-graph: commit-graph: don't consider "replace" objects with "verify" commit-graph tests: fix another graph_git_two_modes() helper commit-graph tests: fix error-hiding graph_git_two_modes() helper
2021-10-31i18n: fix typos found during l10n for git 2.34.0Libravatar Jiang Xin1-1/+1
Emir and Jean-Noël reported typos in some i18n messages when preparing l10n for git 2.34.0. * Fix unstable spelling of config variable "gpg.ssh.defaultKeyCommand" which was introduced in commit fd9e226776 (ssh signing: retrieve a default key from ssh-agent, 2021-09-10). * Add missing space between "with" and "--python" which was introduced in commit bd0708c7eb (ref-filter: add %(raw) atom, 2021-07-26). * Fix unmatched single quote in 'builtin/index-pack.c' which was introduced in commit 8737dab346 (index-pack: refactor renaming in final(), 2021-09-09) [1] https://github.com/git-l10n/git-po/pull/567 Reported-by: Emir Sarı <bitigchi@me.com> Reported-by: Jean-Noël Avila <jn.avila@free.fr> Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-29Merge branch 'ks/submodule-add-message-fix'Libravatar Junio C Hamano1-14/+22
Message regression fix. * ks/submodule-add-message-fix: submodule: drop unused sm_name parameter from append_fetch_remotes() submodule--helper: fix incorrect newlines in an error message
2021-10-29Merge branch 'ab/plug-random-leaks'Libravatar Junio C Hamano4-7/+14
Leakfix. * ab/plug-random-leaks: reflog: free() ref given to us by dwim_log() submodule--helper: fix small memory leaks clone: fix a memory leak of the "git_dir" variable grep: fix a "path_list" memory leak grep: use object_array_clear() in cmd_grep() grep: prefer "struct grep_opt" over its "void *" equivalent
2021-10-29Merge branch 'ab/ref-filter-leakfix'Libravatar Junio C Hamano3-16/+23
"git for-each-ref" family of commands were leaking the ref_sorting instances that hold sorting keys specified by the user; this has been corrected. * ab/ref-filter-leakfix: branch: use ref_sorting_release() ref-filter API user: add and use a ref_sorting_release() tag: use a "goto cleanup" pattern, leak less memory
2021-10-29Merge branch 'jk/http-push-status-fix'Libravatar Junio C Hamano1-0/+4
"git push" client talking to an HTTP server did not diagnose the lack of the final status report from the other side correctly, which has been corrected. * jk/http-push-status-fix: transport-helper: recognize "expecting report" error from send-pack send-pack: complain about "expecting report" with --helper-status
2021-10-29pull: --ff-only should make it a noop when already-up-to-dateLibravatar Junio C Hamano1-1/+28
Earlier, we made sure that "git pull --ff-only" (and "git -c pull.ff=only pull") errors out when our current HEAD is not an ancestor of the tip of the history we are merging, but the condition to trigger the error was implemented incorrectly. Imagine you forked from a remote branch, built your history on top of it, and then attempted to pull from them again. If they have not made any update in the meantime, our current HEAD is obviously not their ancestor, and this new error triggers. Without the --ff-only option, we just report that there is no need to pull; we did the same historically with --ff-only, too. Make sure we do not fail with the recently added check to restore the historical behaviour. Reported-by: Kenneth Arnold <ka37@calvin.edu> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-28builtin/multi-pack-index.c: don't leak concatenated optionsLibravatar Taylor Blau1-0/+4
The `multi-pack-index` builtin dynamically allocates an array of command-line option for each of its separate modes by calling add_common_options() to concatante the common options with sub-command specific ones. Because this operation allocates a new array, we have to be careful to remember to free it. We already do this in the repack and write sub-commands, but verify and expire don't. Rectify this by calling FREE_AND_NULL as the other modes do. Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-28builtin/repack.c: avoid leaking child argumentsLibravatar Taylor Blau1-1/+3
`git repack` invokes a handful of child processes: one to write the actual pack, and optionally ones to repack promisor objects and update the MIDX. Most of these are freed automatically by calling `start_command()` (which invokes it on error) and `finish_command()` which calls it automatically. But repack_promisor_objects() can initialize a child_process, populate its array of arguments, and then return from the function before even calling start_command(). Make sure that the prepared list of arguments is freed by calling child_process_clear() ourselves to avoid leaking memory along this path. Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-28stash: get rid of unused argument in stash_staged()Libravatar Sergey Organov1-3/+3
Unused 'ps' argument was a left-over from original copy-paste of stash_patch(). Removed. Signed-off-by: Sergey Organov <sorganov@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-28pull: honor --no-verify and do not call the commit-msg hookLibravatar Alex Riesen1-0/+6
The option was incorrectly auto-translated to "--no-verify-signatures", which causes the unexpected effect of the hook being called. And an even more unexpected effect of disabling verification of signatures. The manual page describes the option to behave same as the similarly named option of "git merge", which seems to be the original intention of this option in the "pull" command. Signed-off-by: Alexander Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-27builtin/pack-objects.c: don't leak memory via argumentsLibravatar Taylor Blau1-4/+7
When constructing arguments to pass to setup_revision(), pack-objects only frees the memory used by that array after calling get_object_list(). Ensure that we call strvec_clear() whether or not we use the arguments array by cleaning up whenever we exit the function (and rewriting one early return to jump to a label which frees the memory and then returns). We could avoid setting this array up altogether unless we are in the if-else block that calls get_object_list(), but setting up the argument array is intermingled with lots of other side-effects, e.g.: if (exclude_promisor_objects) { use_internal_rev_list = 1; fetch_if_missing = 0; strvec_push(&rp, "--exclude-promisor-objects"); } So it would be awkward to check exclude_promisor_objects twice: first to set use_internal_rev_list and fetch_if_missing, and then again above get_object_list() to push the relevant argument onto the array. Instead, leave the array's construction alone and make sure to free it unconditionally. Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-27submodule: drop unused sm_name parameter from append_fetch_remotes()Libravatar Jeff King1-3/+2
Commit c21fb4676f (submodule--helper: fix incorrect newlines in an error message, 2021-10-23) accidentally added a new, unused parameter while changing the name and signature of show_fetch_remotes() to append_fetch_remotes(). We can drop this to keep things simpler (and satisfy -Wunused-parameter). The error is likely because c21fb4676f is fixing a problem from 8c8195e9c3 (submodule--helper: introduce add-clone subcommand, 2021-07-10). An earlier iteration of that second commit introduced the same unused parameter (though it was dropped before it finally made it to 'next'), and the fix on top accidentally carried forward the extra parameter. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-25Merge branch 'ab/pkt-line-cleanup'Libravatar Junio C Hamano1-2/+2
Code clean-up. * ab/pkt-line-cleanup: pkt-line.[ch]: remove unused packet_read_line_buf() pkt-line.[ch]: remove unused packet_buf_write_len()
2021-10-25Merge branch 'ab/mark-leak-free-tests-more'Libravatar Junio C Hamano2-8/+8
Bunch of tests are marked as "passing leak check". * ab/mark-leak-free-tests-more: merge: add missing strbuf_release() ls-files: add missing string_list_clear() ls-files: fix a trivial dir_clear() leak tests: fix test-oid-array leak, test in SANITIZE=leak tests: fix a memory leak in test-oidtree.c tests: fix a memory leak in test-parse-options.c tests: fix a memory leak in test-prio-queue.c
2021-10-25Merge branch 'ab/parse-options-cleanup'Libravatar Junio C Hamano3-2/+8
Random changes to parse-options implementation. * ab/parse-options-cleanup: parse-options: change OPT_{SHORT,UNSET} to an enum parse-options tests: test optname() output parse-options.[ch]: make opt{bug,name}() "static" commit-graph: stop using optname() parse-options.c: move optname() earlier in the file parse-options.h: make the "flags" in "struct option" an enum parse-options.c: use exhaustive "case" arms for "enum parse_opt_result" parse-options.[ch]: consistently use "enum parse_opt_result" parse-options.[ch]: consistently use "enum parse_opt_flags" parse-options.h: move PARSE_OPT_SHELL_EVAL between enums
2021-10-25Merge branch 'fs/ssh-signing'Libravatar Junio C Hamano1-0/+4
Use ssh public crypto for object and push-cert signing. * fs/ssh-signing: ssh signing: test that gpg fails for unknown keys ssh signing: tests for logs, tags & push certs ssh signing: duplicate t7510 tests for commits ssh signing: verify signatures using ssh-keygen ssh signing: provide a textual signing_key_id ssh signing: retrieve a default key from ssh-agent ssh signing: add ssh key format and signing code ssh signing: add test prereqs ssh signing: preliminary refactoring and clean-up
2021-10-25Merge branch 'ab/fsck-unexpected-type'Libravatar Junio C Hamano4-9/+42
"git fsck" has been taught to report mismatch between expected and actual types of an object better. * ab/fsck-unexpected-type: fsck: report invalid object type-path combinations fsck: don't hard die on invalid object types object-file.c: stop dying in parse_loose_header() object-file.c: return ULHR_TOO_LONG on "header too long" object-file.c: use "enum" return type for unpack_loose_header() object-file.c: simplify unpack_loose_short_header() object-file.c: make parse_loose_header_extended() public object-file.c: return -1, not "status" from unpack_loose_header() object-file.c: don't set "typep" when returning non-zero cat-file tests: test for current --allow-unknown-type behavior cat-file tests: add corrupt loose object test cat-file tests: test for missing/bogus object with -t, -s and -p cat-file tests: move bogus_* variable declarations earlier fsck tests: test for garbage appended to a loose object fsck tests: test current hash/type mismatch behavior fsck tests: refactor one test to use a sub-repo fsck tests: add test for fsck-ing an unknown type
2021-10-23submodule--helper: fix incorrect newlines in an error messageLibravatar Kaartic Sivaraam1-14/+23
A refactoring[1] done as part of the recent conversion of 'git submodule add' to builtin, changed the error message shown when a Git directory already exists locally for a submodule name. Before the refactoring, the error used to appear like so: --- START OF OUTPUT --- $ git submodule add ../sub/ subm A git directory for 'subm' is found locally with remote(s): origin /me/git-repos-for-test/sub If you want to reuse this local git directory instead of cloning again from /me/git-repos-for-test/sub use the '--force' option. If the local git directory is not the correct repo or you are unsure what this means choose another name with the '--name' option. --- END OF OUTPUT --- After the refactoring the error started appearing like so: --- START OF OUTPUT --- $ git submodule add ../sub/ subm A git directory for 'subm' is found locally with remote(s): origin /me/git-repos-for-test/sub fatal: If you want to reuse this local git directory instead of cloning again from /me/git-repos-for-test/sub use the '--force' option. If the local git directory is not the correct repo or if you are unsure what this means, choose another name with the '--name' option. --- END OF OUTPUT --- As one could observe the remote information is printed along with the first line rather than on its own line. Also, there's an additional newline following output. Make the error message consistent with the error message that used to be printed before the refactoring. This also moves the 'fatal:' prefix that appears in the middle of the error message to the first line as it would more appropriate to have it in the first line. The output after the change would look like: --- START OF OUTPUT --- $ git submodule add ../sub/ subm fatal: A git directory for 'subm' is found locally with remote(s): origin /me/git-repos-for-test/sub If you want to reuse this local git directory instead of cloning again from /me/git-repos-for-test/sub use the '--force' option. If the local git directory is not the correct repo or you are unsure what this means choose another name with the '--name' option. --- END OF OUTPUT --- [1]: https://lore.kernel.org/git/20210710074801.19917-5-raykar.ath@gmail.com/#t Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-23reflog: free() ref given to us by dwim_log()Libravatar Ævar Arnfjörð Bjarmason1-0/+1
When dwim_log() returns the "ref" is always ether NULL or an xstrdup()'d string. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-23submodule--helper: fix small memory leaksLibravatar Ævar Arnfjörð Bjarmason1-0/+2
Add a missing strbuf_release() and a clear_pathspec() to the submodule--helper. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-23clone: fix a memory leak of the "git_dir" variableLibravatar Ævar Arnfjörð Bjarmason1-1/+3
At this point in cmd_clone the "git_dir" is always either an xstrdup()'d string, or something we got from mkpathdup(). Let's free() it before we clobber it. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-23grep: fix a "path_list" memory leakLibravatar Ævar Arnfjörð Bjarmason1-4/+5
Free the "path_list" used in builtin/grep.c, it was declared as STRING_LIST_INIT_NODUP, let's change it to a STRING_LIST_INIT_DUP since an early user in cmd_grep() appends a string passed via parse-options.c to it, which needs to be duplicated. Let's then convert the remaining callers to use string_list_append_nodup() instead, allowing us to free the list. This makes all the tests in t7811-grep-open.sh pass, 6/10 would fail before this change. The only remaining failure would have been due to a stray "git checkout" (which still leaks memory). In this case we can use a "git reset --hard" instead, so let's do that, and move the test_when_finished() above the code that would modify the relevant file. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-23grep: use object_array_clear() in cmd_grep()Libravatar Ævar Arnfjörð Bjarmason1-0/+1
Free the "struct object_array" before exiting. This makes grep tests (e.g. "t7815-grep-binary.sh") a bit happer under SANITIZE=leak. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-23grep: prefer "struct grep_opt" over its "void *" equivalentLibravatar Ævar Arnfjörð Bjarmason1-2/+2
Stylistically fix up code added in bfac23d9534 (grep: Fix two memory leaks, 2010-01-30). We usually don't use the "arg" at all once we've casted it to the struct we want, let's not do that here when we're freeing it. Perhaps it was thought that a cast to "void *" would otherwise be needed? Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-20for-each-ref: delay parsing of --sort=<atom> optionsLibravatar Junio C Hamano4-23/+24
The for-each-ref family of commands invoke parsers immediately when it sees each --sort=<atom> option, and die before even seeing the other options on the command line when the <atom> is unrecognised. Instead, accumulate them in a string list, and have them parsed into a ref_sorting structure after the command line parsing is done. As a consequence, "git branch --sort=bogus -h" used to fail to give the brief help, which arguably may have been a feature, now does so, which is more consistent with how other options work. The patch is smaller than the actual extent of the "damage" to the codebase, thanks to the fact that the original code consistently used OPT_REF_SORT() macro to handle command line options. We only needed to replace the variable used for the list, and implementation of the callback function used in the macro. The old rule was for the users of the API to: - Declare ref_sorting and ref_sorting_tail variables; - OPT_REF_SORT() macro will instantiate ref_sorting instance (which may barf and die) and append it to the tail; - Append to the tail each ref_sorting read from the configuration by parsing in the config callback (which may barf and die); - See if ref_sorting is null and use ref_sorting_default() instead. Now the rule is not all that different but is simpler: - Declare ref_sorting_options string list. - OPT_REF_SORT() macro will append it to the string list; - Append to the string list the sort key read from the configuration; - call ref_sorting_options() to turn the string list to ref_sorting structure (which also deals with the default value). As side effects, this change also cleans up a few issues: - 95be717c (parse_opt_ref_sorting: always use with NONEG flag, 2019-03-20) muses that "git for-each-ref --no-sort" should simply clear the sort keys accumulated so far; it now does. - The implementation detail of "struct ref_sorting" and the helper function parse_ref_sorting() can now be private to the ref-filter API implementation. - If you set branch.sort to a bogus value, the any "git branch" invocation, not only the listing mode, would abort with the original code; now it doesn't Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-20branch: use ref_sorting_release()Libravatar Ævar Arnfjörð Bjarmason1-3/+5
Use a ref_sorting_release() in branch.c to free the memory from the ref_sorting_options(). This plugs the final in-tree memory leak of that API. In the preceding commit the "sorting" variable was left in the cmd_branch() scope, even though that wasn't needed anymore. Move it to the "else if (list)" scope instead. We can also move the "struct string_list" only used for that branch to be declared in that block That "struct ref_sorting" does not need to be "static" (and isn't re-used). The "ref_sorting_options()" will return a valid one, we don't need to make it "static" to have it zero'd out. That it was static was another artifact of the pre-image of the preceding commit. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-20ref-filter API user: add and use a ref_sorting_release()Libravatar Ævar Arnfjörð Bjarmason2-1/+2
Add a ref_sorting_release() and use it for some of the current API users, the ref_sorting_default() function and its siblings will do a malloc() which wasn't being free'd previously. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-20tag: use a "goto cleanup" pattern, leak less memoryLibravatar Ævar Arnfjörð Bjarmason1-12/+16
Change cmd_tag() to free its "struct strbuf"'s instead of using an UNLEAK() pattern. This changes code added in 886e1084d78 (builtin/: add UNLEAKs, 2017-10-01). As shown in the context of the declaration of the "struct msg_arg" (which I'm changing to use a designated initializer while at it, and to show the context in this change), that struct is just a thin wrapper around an int and "struct strbuf". Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-18Merge branch 'jk/cat-file-batch-all-wo-replace'Libravatar Junio C Hamano1-14/+40
"git cat-file --batch" with the "--batch-all-objects" option is supposed to iterate over all the objects found in a repository, but it used to translate these object names using the replace mechanism, which defeats the point of enumerating all objects in the repository. This has been corrected. * jk/cat-file-batch-all-wo-replace: cat-file: use packed_object_info() for --batch-all-objects cat-file: split ordered/unordered batch-all-objects callbacks cat-file: disable refs/replace with --batch-all-objects cat-file: mention --unordered along with --batch-all-objects t1006: clean up broken objects
2021-10-18Merge branch 'ab/designated-initializers-more'Libravatar Junio C Hamano3-74/+69
Code clean-up. * ab/designated-initializers-more: builtin/remote.c: add and use SHOW_INFO_INIT builtin/remote.c: add and use a REF_STATES_INIT urlmatch.[ch]: add and use URLMATCH_CONFIG_INIT builtin/blame.c: refactor commit_info_init() to COMMIT_INFO_INIT macro daemon.c: refactor hostinfo_init() to HOSTINFO_INIT macro
2021-10-18Merge branch 'tb/repack-write-midx'Libravatar Junio C Hamano2-36/+282
"git repack" has been taught to generate multi-pack reachability bitmaps. * tb/repack-write-midx: test-read-midx: fix leak of bitmap_index struct builtin/repack.c: pass `--refs-snapshot` when writing bitmaps builtin/repack.c: make largest pack preferred builtin/repack.c: support writing a MIDX while repacking builtin/repack.c: extract showing progress to a variable builtin/repack.c: rename variables that deal with non-kept packs builtin/repack.c: keep track of existing packs unconditionally midx: preliminary support for `--refs-snapshot` builtin/multi-pack-index.c: support `--stdin-packs` mode midx: expose `write_midx_file_only()` publicly