git/git.c, branch v2.47.2

Merge branch 'ps/leakfixes-part-7'

2024-10-02T14:46:26Z

More leak-fixes. * ps/leakfixes-part-7: (23 commits) diffcore-break: fix leaking filespecs when merging broken pairs revision: fix leaking parents when simplifying commits builtin/maintenance: fix leak in `get_schedule_cmd()` builtin/maintenance: fix leaking config string promisor-remote: fix leaking partial clone filter grep: fix leaking grep pattern submodule: fix leaking submodule ODB paths trace2: destroy context stored in thread-local storage builtin/difftool: plug several trivial memory leaks builtin/repack: fix leaking configuration diffcore-order: fix leaking buffer when parsing orderfiles parse-options: free previous value of `OPTION_FILENAME` diff: fix leaking orderfile option builtin/pull: fix leaking "ff" option dir: fix off by one errors for ignored and untracked entries builtin/submodule--helper: fix leaking remote ref on errors t/helper: fix leaking subrepo in nested submodule config helper builtin/submodule--helper: fix leaking error buffer builtin/submodule--helper: clear child process when not running it submodule: fix leaking update strategy ...

git: fix leaking argv when handling builtins

2024-09-27T15:25:34Z

In `handle_builtin()` we may end up creating an ad-hoc argv array in case we see that the command line contains the "--help" parameter. In this case we observe two memory leaks though: - We leak the `struct strvec` itself because we directly exit after calling `run_builtin()`, without bothering about any cleanups. - Even if we free'd that vector we'd end up leaking some of its strings because `run_builtin()` will modify the array. Plug both of these leaks. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

builtin: add a repository parameter for builtin functions

2024-09-13T21:27:08Z

In order to reduce the usage of the global the_repository, add a parameter to builtin functions that will get passed a repository variable. This commit uses UNUSED on most of the builtin functions, as subsequent commits will modify the actual builtins to pass the repository parameter down. Signed-off-by: John Cai Signed-off-by: Junio C Hamano

git: fix leaking system paths

2024-08-14T17:07:56Z

Git has some flags to make it output system paths as they have been compiled into Git. This is done by calling `system_path()`, which returns an allocated string. This string isn't ever free'd though, creating a memory leak. Plug those leaks. While they are surfaced by t0211, there are more memory leaks looming exposed by that test suite and it thus does not yet pass with the memory leak checker enabled. Helped-by: Taylor Blau Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

global: introduce `USE_THE_REPOSITORY_VARIABLE` macro

2024-06-14T17:26:33Z

Use of the `the_repository` variable is deprecated nowadays, and we slowly but steadily convert the codebase to not use it anymore. Instead, callers should be passing down the repository to work on via parameters. It is hard though to prove that a given code unit does not use this variable anymore. The most trivial case, merely demonstrating that there is no direct use of `the_repository`, is already a bit of a pain during code reviews as the reviewer needs to manually verify claims made by the patch author. The bigger problem though is that we have many interfaces that implicitly rely on `the_repository`. Introduce a new `USE_THE_REPOSITORY_VARIABLE` macro that allows code units to opt into usage of `the_repository`. The intent of this macro is to demonstrate that a certain code unit does not use this variable anymore, and to keep it from new dependencies on it in future changes, be it explicit or implicit For now, the macro only guards `the_repository` itself as well as `the_hash_algo`. There are many more known interfaces where we have an implicit dependency on `the_repository`, but those are not guarded at the current point in time. Over time though, we should start to add guards as required (or even better, just remove them). Define the macro as required in our code units. As expected, most of our code still relies on the global variable. Nearly all of our builtins rely on the variable as there is no way yet to pass `the_repository` to their entry point. For now, declare the macro in "biultin.h" to keep the required changes at least a little bit more contained. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

builtin/refs: new command to migrate ref storage formats

2024-06-06T16:04:34Z

Introduce a new command that allows the user to migrate a repository between ref storage formats. This new command is implemented as part of a new git-refs(1) executable. This is due to two reasons: - There is no good place to put the migration logic in existing commands. git-maintenance(1) felt unwieldy, and git-pack-refs(1) is not the correct place to put it, either. - I had it in my mind to create a new low-level command for accessing refs for quite a while already. git-refs(1) is that command and can over time grow more functionality relating to refs. This should help discoverability by consolidating low-level access to refs into a single executable. As mentioned in the preceding commit that introduces the ref storage format migration logic, the new `git refs migrate` command still has a bunch of restrictions. These restrictions are documented accordingly. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

advice: add --no-advice global option

2024-05-03T17:36:59Z

Advice hints must be disabled individually by setting the relevant advice.* variables to false in the Git configuration. For server-side and scripted usages of Git where hints can be a hindrance, it can be cumbersome to maintain configuration to ensure all advice hints are disabled in perpetuity. This is a particular concern in tests, where new or changed hints can result in failed assertions. Add a --no-advice global option to disable all advice hints from being displayed. This is independent of the toggles for individual advice hints. Use an internal environment variable (GIT_ADVICE) to ensure this configuration is propagated to the usage site, even if it executes in a subprocess. Signed-off-by: James Liu Signed-off-by: Junio C Hamano

doc: clean up usage documentation for --no-* opts

2024-05-03T17:32:06Z

We'll be adding another option to the --no-* class of options soon. Clean up the existing options by grouping them together in the OPTIONS section, and adding missing ones to the SYNOPSIS. Signed-off-by: James Liu Signed-off-by: Junio C Hamano

Merge branch 'jh/trace2-missing-def-param-fix'

2024-03-18T20:04:25Z

Some trace2 events that lacked def_param have learned to show it, enriching the output. Reviewed-by: Josh Steadmon cf. * jh/trace2-missing-def-param-fix: trace2: emit 'def_param' set with 'cmd_name' event trace2: avoid emitting 'def_param' set more than once t0211: demonstrate missing 'def_param' events for certain commands

Merge branch 'jc/no-lazy-fetch'

2024-03-07T23:59:40Z

"git --no-lazy-fetch cmd" allows to run "cmd" while disabling lazy fetching of objects from the promisor remote, which may be handy for debugging. * jc/no-lazy-fetch: git: extend --no-lazy-fetch to work across subprocesses git: document GIT_NO_REPLACE_OBJECTS environment variable git: --no-lazy-fetch option