git/builtin/pull.c, branch v2.40.2

{builtin/*,repository}.c: add & use "USE_THE_INDEX_VARIABLE"

2022-11-21T03:06:15Z

Split up the "USE_THE_INDEX_COMPATIBILITY_MACROS" into that setting and a more narrow "USE_THE_INDEX_VARIABLE". In the case of these built-ins we only need "the_index" variable, but not the compatibility wrapper for functions we're not using. Let's then have some users of "USE_THE_INDEX_COMPATIBILITY_MACROS" use this more narrow and descriptive define. For context: The USE_THE_INDEX_COMPATIBILITY_MACROS macro was added to test-tool.h in f8adbec9fea (cache.h: flip NO_THE_INDEX_COMPATIBILITY_MACROS switch, 2019-01-24). Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

cocci & cache.h: remove rarely used "the_index" compat macros

2022-11-21T03:06:15Z

Since 4aab5b46f44 (Make read-cache.c "the_index" free., 2007-04-01) we've been undergoing a slow migration away from these macros, but haven't made much progress since f8adbec9fea (cache.h: flip NO_THE_INDEX_COMPATIBILITY_MACROS switch, 2019-01-24). Let's move forward a bit by changing the users of those macros that are rare enough that we can convert them in one go, and then remove the compatibility shim. The only manual change to the C code here is to "cache.h", the rest is all the result of applying the new "index-compatibility.cocci". Even though it's a one-off, let's keep the coccinelle rules for now. We'll extend them in subsequent commits, and this will help anything that's in-flight or out-of-tree to migrate. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

use child_process members "args" and "env" directly

2022-10-30T18:04:40Z

Build argument list and environment of child processes by using struct child_process and populating its members "args" and "env" directly instead of maintaining separate strvecs and letting run_command_v_opt() and friends populate these members. This is simpler, shorter and slightly more efficient. Signed-off-by: René Scharfe Signed-off-by: Taylor Blau

pull: fix a "struct oid_array" memory leak

2022-07-01T18:43:43Z

Fix a memory leak introduced in 44c175c7a46 (pull: error on no merge candidates, 2015-06-18). As a result we can mark several tests as passing with SANITIZE=leak using "TEST_PASSES_SANITIZE_LEAK=true". Removing the "int ret = 0" assignment added here in a6d7eb2c7a6 (pull: optionally rebase submodules (remote submodule changes only), 2017-06-23) is not a logic error, it could always have been left uninitialized (as "int ret"), now that we'll use the "ret" from the upper scope we can drop the assignment in the "opt_rebase" branch. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

Merge branch 'gc/pull-recurse-submodules'

2022-05-20T22:26:57Z

"git pull" without "--recurse-submodules=" made submodule.recurse take precedence over fetch.recurseSubmodules by mistake, which has been corrected. * gc/pull-recurse-submodules: pull: do not let submodule.recurse override fetch.recurseSubmodules

pull: do not let submodule.recurse override fetch.recurseSubmodules

2022-05-11T22:42:30Z

Fix a bug in "git pull" where `submodule.recurse` is preferred over `fetch.recurseSubmodules` when performing a fetch (Documentation/config/fetch.txt says that `fetch.recurseSubmodules` should be preferred.). Do this by passing the value of the "--recurse-submodules" CLI option to the underlying fetch, instead of passing a value that combines the CLI option and config variables. In other words, this bug occurred because builtin/pull.c is conflating two similar-sounding, but different concepts: - Whether "git pull" itself should care about submodules e.g. whether it should update the submodule worktrees after performing a merge. - The value of "--recurse-submodules" to pass to the underlying "git fetch". Thus, when `submodule.recurse` is set, the underlying "git fetch" gets invoked with "--recurse-submodules[=value]", overriding the value of `fetch.recurseSubmodules`. An alternative (and more obvious) approach to fix the bug would be to teach "git pull" to understand `fetch.recurseSubmodules`, but the proposed solution works better because: - We don't maintain two identical config-parsing implementions in "git pull" and "git fetch". - It works better with other commands invoked by "git pull" e.g. "git merge" won't accidentally respect `fetch.recurseSubmodules`. Reported-by: Huang Zou Helped-by: Philippe Blain Signed-off-by: Glen Choo Signed-off-by: Junio C Hamano

Merge branch 'ja/i18n-common-messages'

2022-02-25T23:47:35Z

Unify more messages to help l10n. * ja/i18n-common-messages: i18n: fix some misformated placeholders in command synopsis i18n: remove from i18n strings that do not hold translatable parts i18n: factorize "invalid value" messages i18n: factorize more 'incompatible options' messages

Merge branch 'js/short-help-outside-repo-fix'

2022-02-18T21:53:30Z

"git cmd -h" outside a repository should error out cleanly for many commands, but instead it hit a BUG(), which has been corrected. * js/short-help-outside-repo-fix: t0012: verify that built-ins handle `-h` even without gitdir checkout/fetch/pull/pack-objects: allow `-h` outside a repository

checkout/fetch/pull/pack-objects: allow `-h` outside a repository

2022-02-08T17:54:44Z

When we taught these commands about the sparse index, we did not account for the fact that the `cmd_*()` functions _can_ be called without a gitdir, namely when `-h` is passed to show the usage. A plausible approach to address this is to move the `prepare_repo_settings()` calls right after the `parse_options()` calls: The latter will never return when it handles `-h`, and therefore it is safe to assume that we have a `gitdir` at that point, as long as the built-in is marked with the `RUN_SETUP` flag. However, it is unfortunately not that simple. In `cmd_pack_objects()`, for example, the repo settings need to be fully populated so that the command-line options `--sparse`/`--no-sparse` can override them, not the other way round. Therefore, we choose to imitate the strategy taken in `cmd_diff()`, where we simply do not bother to prepare and initialize the repo settings unless we have a `gitdir`. This fixes https://github.com/git-for-windows/git/issues/3688 Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

Merge branch 'pb/pull-rebase-autostash-fix'

2022-02-05T17:42:28Z

"git pull --rebase" ignored the rebase.autostash configuration variable when the remote history is a descendant of our history, which has been corrected. * pb/pull-rebase-autostash-fix: pull --rebase: honor rebase.autostash when fast-forwarding