git/git.c, branch v2.40.2

trace.c, git.c: remove unnecessary parameter to trace_repo_setup()

2023-02-21T20:06:32Z

trace_repo_setup() of trace.c is called with the argument 'prefix' from only one location, run_builtin of git.c, which sets 'prefix' to the return value of setup_git_directory() or setup_git_directory_gently() (a wrapper of the former). Now that "prefix" is in startup_info there is no need for the parameter of trace_repo_setup() because setup_git_directory() sets "startup_info->prefix" to the same value it returns. It would be less confusing to use "prefix" from startup_info instead of passing it as an argument. Signed-off-by: Idriss Fekir Signed-off-by: Junio C Hamano

Merge branch 'ab/test-env-helper'

2023-01-23T21:39:51Z

Remove "git env--helper" and demote it to a test-tool subcommand. * ab/test-env-helper: env-helper: move this built-in to "test-tool env-helper"

env-helper: move this built-in to "test-tool env-helper"

2023-01-15T02:07:11Z

Since [1] there has been no reason for keeping "git env--helper" a built-in. The reason it was a built-in to begin with was to support the GIT_TEST_GETTEXT_POISON mode removed in that commit. I.e. unlike the rest of "test-tool" it would potentially be called by the installed git via "git-sh-i18n.sh". As none of that applies since [1] we should stop carrying this technical debt, and move it to t/helper/*. As this mostly move-only change shows this has the nice bonus that we'll stop wasting time translating the internal-only strings it emits. Even though this was a built-in, it was intentionally never documented, see its introduction in [2]. It never saw use outside of the test suite, except for the "GIT_TEST_GETTEXT_POISON" use-case noted above. 1. d162b25f956 (tests: remove support for GIT_TEST_GETTEXT_POISON, 2021-01-20) 2. b4f207f3394 (env--helper: new undocumented builtin wrapping git_env_*(), 2019-06-21) Signed-off-by: Ævar Arnfjörð Bjarmason Acked-by: Jeff King Signed-off-by: Junio C Hamano

read-tree: add "--super-prefix" option, eliminate global

2022-12-26T01:21:44Z

The "--super-prefix" option to "git" was initially added in [1] for use with "ls-files"[2], and shortly thereafter "submodule--helper"[3] and "grep"[4]. It wasn't until [5] that "read-tree" made use of it. At the time [5] made sense, but since then we've made "ls-files" recurse in-process in [6], "grep" in [7], and finally "submodule--helper" in the preceding commits. Let's also remove it from "read-tree", which allows us to remove the option to "git" itself. We can do this because the only remaining user of it is the submodule API, which will now invoke "read-tree" with its new "--super-prefix" option. It will only do so when the "submodule_move_head()" function is called. That "submodule_move_head()" function was then only invoked by "read-tree" itself, but now rather than setting an environment variable to pass "--super-prefix" between cmd_read_tree() we: - Set a new "super_prefix" in "struct unpack_trees_options". The "super_prefixed()" function in "unpack-trees.c" added in [5] will now use this, rather than get_super_prefix() looking up the environment variable we set earlier in the same process. - Add the same field to the "struct checkout", which is only needed to ferry the "super_prefix" in the "struct unpack_trees_options" all the way down to the "entry.c" callers of "submodule_move_head()". Those calls which used the super prefix all originated in "cmd_read_tree()". The only other caller is the "unlink_entry()" caller in "builtin/checkout.c", which now passes a "NULL". 1. 74866d75793 (git: make super-prefix option, 2016-10-07) 2. e77aa336f11 (ls-files: optionally recurse into submodules, 2016-10-07) 3. 89c86265576 (submodule helper: support super prefix, 2016-12-08) 4. 0281e487fd9 (grep: optionally recurse into submodules, 2016-12-16) 5. 3d415425c7b (unpack-trees: support super-prefix option, 2017-01-17) 6. 188dce131fa (ls-files: use repository object, 2017-06-22) 7. f9ee2fcdfa0 (grep: recurse in-process using 'struct repository', 2017-08-02) Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

submodule--helper: convert "{update,clone}" to their own "--super-prefix"

2022-12-26T01:21:44Z

As with a preceding commit to convert "absorbgitdirs", we can convert "submodule--helper status" to use its own "--super-prefix", instead of relying on the global "--super-prefix" argument to "git". We need to convert both of these away from the global "--super-prefix" at the same time, because "update" will call "clone", but "clone" itself didn't make use of the global "--super-prefix" for displaying paths. It was only on the list of sub-commands that accepted it because "update"'s use of it would set it in its environment. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

submodule--helper: don't use global --super-prefix in "absorbgitdirs"

2022-12-26T01:21:43Z

The "--super-prefix" facility was introduced in [1] has always been a transitory hack, which is why we've made it an error to supply it as an option to "git" to commands that don't know about it. That's been a good goal, as it has a global effect we haven't wanted calls to get_super_prefix() from built-ins we didn't expect. But it has meant that when we've had chains of different built-ins using it all of the processes in that "chain" have needed to support it, and worse processes that don't need it have needed to ask for "SUPPORT_SUPER_PREFIX" because their parent process needs it. That's how "fsmonitor--daemon" ended up with it, per [2] it's called from (among other things) "submodule--helper absorbgitdirs", but as we declared "submodule--helper" as "SUPPORT_SUPER_PREFIX" we needed to declare "fsmonitor--daemon" as accepting it too, even though it doesn't care about it. But in the case of "absorbgitdirs" it only needed "--super-prefix" to invoke itself recursively, and we'd never have another "in-between" process in the chain. So we didn't need the bigger hammer of "git --super-prefix", and the "setenv(GIT_SUPER_PREFIX_ENVIRONMENT, ...)" that it entails. Let's instead accept a hidden "--super-prefix" option to "submodule--helper absorbgitdirs" itself. Eventually (as with all other "--super-prefix" users) we'll want to clean this code up so that this all happens in-process. I.e. needing any variant of "--super-prefix" is itself a hack around our various global state, and implicit reliance on "the_repository". This stepping stone makes such an eventual change easier, as we'll need to deal with less global state at that point. The "fsmonitor--daemon" test adjusted here was added in [3]. To assert that it didn't run into the "--super-prefix" message it was asserting the output it didn't have. Let's instead assert the full output that we *do* have, using the same pattern as a preceding change to "t/t7412-submodule-absorbgitdirs.sh" used. We could also remove the test entirely (as [4] did), but even though the initial reason for having it is gone we're still getting some marginal benefit from testing the "fsmonitor" and "submodule absorbgitdirs" interaction, so let's keep it. The change here to have either a NULL or non-"" string as a "super_prefix" instead of the previous arrangement of "" or non-"" is somewhat arbitrary. We could also decide to never have to check for NULL. As we'll be changing the rest of the "git --super-prefix" users to the same pattern, leaving them all consistent makes sense. Why not pick "" over NULL? Because that's how the "prefix" works[5], and having "prefix" and "super_prefix" work the same way will be less confusing. That "prefix" picked NULL instead of "" is itself arbitrary, but as it's easy to make this small bit of our overall API consistent, let's go with that. 1. 74866d75793 (git: make super-prefix option, 2016-10-07) 2. 53fcfbc84f6 (fsmonitor--daemon: allow --super-prefix argument, 2022-05-26) 3. 53fcfbc84f6 (fsmonitor--daemon: allow --super-prefix argument, 2022-05-26) 4. https://lore.kernel.org/git/20221109004708.97668-5-chooglen@google.com/ 5. 9725c8dda20 (built-ins: trust the "prefix" from run_builtin(), 2022-02-16) Signed-off-by: Glen Choo Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

Merge branch 'dd/git-bisect-builtin'

2022-12-14T06:55:45Z

`git bisect` becomes a builtin. * dd/git-bisect-builtin: bisect; remove unused "git-bisect.sh" and ".gitignore" entry Turn `git bisect` into a full built-in bisect--helper: log: allow arbitrary number of arguments bisect--helper: handle states directly bisect--helper: emit usage for "git bisect" bisect test: test exit codes on bad usage bisect--helper: identify as bisect when report error bisect-run: verify_good: account for non-negative exit status bisect run: keep some of the post-v2.30.0 output bisect: fix output regressions in v2.30.0 bisect: refactor bisect_run() to match CodingGuidelines bisect tests: test for v2.30.0 "bisect run" regressions

Merge branch 'ab/submodule-helper-prep-only'

2022-11-23T02:22:22Z

Preparation to remove git-submodule.sh and replace it with a builtin. * ab/submodule-helper-prep-only: submodule--helper: use OPT_SUBCOMMAND() API submodule--helper: drop "update --prefix " for "-C update" submodule--helper: remove --prefix from "absorbgitdirs" submodule API & "absorbgitdirs": remove "----recursive" option submodule.c: refactor recursive block out of absorb function submodule tests: test for a "foreach" blind-spot submodule--helper: fix a memory leak in "status" submodule tests: add tests for top-level flag output submodule--helper: move "config" to a test-tool

Turn `git bisect` into a full built-in

2022-11-11T22:06:02Z

Now that the shell script hands off to the `bisect--helper` to do _anything_ (except to show the help), it is but a tiny step to let the helper implement the actual `git bisect` command instead. This retires `git-bisect.sh`, concluding a multi-year journey that many hands helped with, in particular Pranit Bauna, Tanushree Tumane and Miriam Rubio. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano Signed-off-by: Đoàn Trần Công Danh Signed-off-by: Taylor Blau

submodule--helper: use OPT_SUBCOMMAND() API

2022-11-08T19:55:30Z

Have the cmd_submodule__helper() use the OPT_SUBCOMMAND() API introduced in fa83cc834da (parse-options: add support for parsing subcommands, 2022-08-19). This is only a marginal reduction in line count, but once we start unifying this with a yet-to-be-added "builtin/submodule.c" it'll be much easier to reason about those changes, as they'll both use OPT_SUBCOMMAND(). We don't need to worry about "argv[0]" being NULL in the die() because we'd have errored out in parse_options() as we're not using "PARSE_OPT_SUBCOMMAND_OPTIONAL". Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Taylor Blau