git/git.c, branch main

use strvec_pushv() to add another strvec

2026-03-24T19:26:58Z

Add and apply a semantic patch that simplifies the code by letting strvec_pushv() append the items of a second strvec instead of pushing them one by one. Suggested-by: Junio C Hamano Signed-off-by: René Scharfe Signed-off-by: Junio C Hamano

Merge branch 'jh/alias-i18n-fixes'

2026-03-10T21:23:24Z

Further update to the i18n alias support to avoid regressions. * jh/alias-i18n-fixes: doc: fix list continuation in alias.adoc git, help: fix memory leaks in alias listing alias: treat empty subsection [alias ""] as plain [alias] doc: fix list continuation in alias subsection example

Merge branch 'ar/config-hooks'

2026-03-10T21:23:18Z

Allow hook commands to be defined (possibly centrally) in the configuration files, and run multiple of them for the same hook event. * ar/config-hooks: hook: add -z option to "git hook list" hook: allow out-of-repo 'git hook' invocations hook: allow event = "" to overwrite previous values hook: allow disabling config hooks hook: include hooks from the config hook: add "git hook list" command hook: run a list of hooks to prepare for multihook support hook: add internal state alloc/free callbacks

git, help: fix memory leaks in alias listing

2026-02-26T21:07:24Z

The list_aliases() function sets the util pointer of each list item to a heap-allocated copy of the alias command value. Two callers failed to free these util pointers: - list_cmds() in git.c collects a string list with STRING_LIST_INIT_DUP and clears it with string_list_clear(&list, 0), which frees the duplicated strings (strdup_strings=1) but not the util pointers. Pass free_util=1 to free them. - list_cmds_by_config() in help.c calls string_list_sort_u(list, 0) to deduplicate the list before processing completion.commands overrides. When duplicate entries are removed, the util pointer of each discarded item is leaked because free_util=0. Pass free_util=1 to free them. Reported-by: Jacob Keller Signed-off-by: Jonatan Holmgren Signed-off-by: Junio C Hamano

hook: allow out-of-repo 'git hook' invocations

2026-02-19T21:24:39Z

Since hooks can now be supplied via the config, and a config can be present without a gitdir via the global and system configs, we can start to allow 'git hook run' to occur without a gitdir. This enables us to do things like run sendemail-validate hooks when running 'git send-email' from a nongit directory. It still doesn't make sense to look for hooks in the hookdir in nongit repos, though, as there is no hookdir. Signed-off-by: Emily Shaffer Signed-off-by: Adrian Ratiu Signed-off-by: Junio C Hamano

builtin: add new "history" command

2026-01-13T13:41:17Z

When rewriting history via git-rebase(1) there are a few very common use cases: - The ordering of two commits should be reversed. - A commit should be split up into two commits. - A commit should be dropped from the history completely. - Multiple commits should be squashed into one. - Editing an existing commit that is not the tip of the current branch. While these operations are all doable, it often feels needlessly kludgey to do so by doing an interactive rebase, using the editor to say what one wants, and then perform the actions. Also, some operations like splitting up a commit into two are way more involved than that and require a whole series of commands. Rebases also do not update dependent branches. The use of stacked branches has grown quite common with competing version control systems like Jujutsu though, so it clearly is a need that users have. While rebases _can_ serve this use case if one always works on the latest stacked branch, it is somewhat awkward and very easy to get wrong. Add a new "history" command to plug these gaps. This command will have several different subcommands to imperatively rewrite history for common use cases like the above. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

Merge branch 'kh/you-still-use-whatchanged-fix'

2025-10-02T19:26:12Z

The "do you still use it?" message given by a command that is deeply deprecated and allow us to suggest alternatives has been updated. * kh/you-still-use-whatchanged-fix: BreakingChanges: remove claim about whatchanged reports whatchanged: remove not-even-shorter clause whatchanged: hint about git-log(1) and aliasing you-still-use-that??: help the user help themselves t0014: test shadowing of aliases for a sample of builtins git: allow alias-shadowing deprecated builtins git: move seen-alias bookkeeping into handle_alias(...) git: add `deprecated` category to --list-cmds Makefile: don’t add whatchanged after it has been removed

git: allow alias-shadowing deprecated builtins

2025-09-17T20:47:23Z

git-whatchanged(1) is deprecated and you need to pass `--i-still-use-this` in order to force it to work as before. There are two affected users, or usages: 1. people who use the command in scripts; and 2. people who are used to using it interactively. For (1) the replacement is straightforward.[1] But people in (2) might like the name or be really used to typing it.[3] An obvious first thought is to suggest aliasing `whatchanged` to the git-log(1) equivalent.[1] But this doesn’t work and is awkward since you cannot shadow builtins via aliases. Now you are left in an uncomfortable limbo; your alias won’t work until the command is removed for good. Let’s lift this limitation by allowing *deprecated* builtins to be shadowed by aliases. The only observed demand for aliasing has been for git-whatchanged(1), not for git-pack-redundant(1). But let’s be consistent and treat all deprecated commands the same. [1]: git log --raw --no-merges With a minor caveat: you get different outputs if you happen to have empty commits (no changes)[2] [2]: https://lore.kernel.org/git/20250825085428.GA367101@coredump.intra.peff.net/ [3]: https://lore.kernel.org/git/BL3P221MB0449288C8B0FA448A227FD48833AA@BL3P221MB0449.NAMP221.PROD.OUTLOOK.COM/ Based-on-patch-by: Jeff King Signed-off-by: Kristoffer Haugsbakk Signed-off-by: Junio C Hamano

git: move seen-alias bookkeeping into handle_alias(...)

2025-09-17T20:47:23Z

We are about to complicate the command handling by allowing *deprecated* builtins to be shadowed by aliases. We need to organize the code in order to facilitate that.[1] The code in the `while(1)` speculatively adds commands to the list before finding out if it’s an alias. Let’s instead move it inside `handle_alias(...)`—where it conceptually belongs anyway—and in turn only run this logic when we have found an alias.[2] [1]: We will do that with an additional call to `handle_alias(1)` inside the loop. *Not* moving this code leaves a blind spot; we will miss alias looping crafted via deprecated builtin names [2]: Also rename the list to a more descriptive name Based-on-patch-by: Jeff King Signed-off-by: Kristoffer Haugsbakk Signed-off-by: Junio C Hamano

git: add `deprecated` category to --list-cmds

2025-09-17T20:47:22Z

With 145 builtin commands (according to `git --list-cmds=builtins`), users are probably not keeping on top of which ones (if any) are deprecated. Let’s expand the experimental `--list-cmds`[1] to allow users and programs to query for this information. We will also use this in an upcoming commit to implement `is_deprecated_command`. [1]: Using something which is experimental to query for deprecations is perhaps not the most ideal approach, but it is simple to implement and better than having to scan the documentation Acked-by: Patrick Steinhardt Helped-by: Patrick Steinhardt Signed-off-by: Kristoffer Haugsbakk Signed-off-by: Junio C Hamano