git/git.c, branch v2.51.2

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

git: show alias info only with lone -h

2025-07-25T23:34:13Z

Builtin commands show usage information on stdout if called with -h as their only option, usage.c::show_usage_if_asked() makes sure of that. Aliases show alias information on stderr if called with -h as the first option since a9a60b94cc (git.c: handle_alias: prepend alias info when first argument is -h, 2018-10-09). This is surprising when using aliases for commands that take -h as a normal argument among others, like git grep. Tighten the condition and show the alias information only if -h is the only option given, to be consistent with builtins. It's probably still is a good idea to write to stderr, as an alias command doesn't have to be a builtin and could instead produce output with just -h that might be spoiled by an extra alias info line. Reported-by: Kevin Brodsky Signed-off-by: René Scharfe Signed-off-by: Junio C Hamano

Merge branch 'jc/you-still-use-whatchanged'

2025-06-25T21:07:35Z

"git whatchanged" that is longer to type than "git log --raw" which is its modern rough equivalent has outlived its usefulness more than 10 years ago. Plan to deprecate and remove it. * jc/you-still-use-whatchanged: whatschanged: list it in BreakingChanges document whatchanged: remove when built with WITH_BREAKING_CHANGES whatchanged: require --i-still-use-this tests: prepare for a world without whatchanged doc: prepare for a world without whatchanged you-still-use-that??: help deprecating commands for removal

git.c: remove the_repository dependence in run_builtin()

2025-06-16T15:17:12Z

run_builtin() takes a repo parameter, so the use of the_repository is no longer necessary. Removed the usage of the_repository. Signed-off-by: Lidong Yan <502024330056@smail.nju.edu.cn> Signed-off-by: Junio C Hamano

whatchanged: remove when built with WITH_BREAKING_CHANGES

2025-05-12T22:30:12Z

As we made "git whatchanged" require "--i-still-use-this" and asked the users to report if they still want to use it, the logical next step is to allow us build Git without "whatchanged" to prepare for its eventual removal. If we were to follow the pattern established in 8ccc75c2 (remote: announce removal of "branches/" and "remotes/", 2025-01-22), we can do this together with the documentation update to officially list that the command will be removed in the BreakingChanges document, but let's just keep the changes separate just in case we want to proceed a bit slower. Signed-off-by: Junio C Hamano

builtin: introduce diff-pairs command

2025-03-03T16:17:47Z

Through git-diff(1), a single diff can be generated from a pair of blob revisions directly. Unfortunately, there is not a mechanism to compute batches of specific file pair diffs in a single process. Such a feature is particularly useful on the server-side where diffing between a large set of changes is not feasible all at once due to timeout concerns. To facilitate this, introduce git-diff-pairs(1) which acts as a backend passing its NUL-terminated raw diff format input from stdin through diff machinery to produce various forms of output such as patch or raw. The raw format was originally designed as an interchange format and represents the contents of the diff_queued_diff list making it possible to break the diff pipeline into separate stages. For example, git-diff-tree(1) can be used as a frontend to compute file pairs to queue and feed its raw output to git-diff-pairs(1) to compute patches. With this, batches of diffs can be progressively generated without having to recompute renames or retrieve object context. Something like the following: git diff-tree -r -z -M $old $new | git diff-pairs -p -z should generate the same output as `git diff-tree -p -M`. Furthermore, each line of raw diff formatted input can also be individually fed to a separate git-diff-pairs(1) process and still produce the same output. Based-on-patch-by: Jeff King Signed-off-by: Justin Tobler Signed-off-by: Junio C Hamano

backfill: add builtin boilerplate

2025-02-04T00:12:41Z

In anticipation of implementing 'git backfill', populate the necessary files with the boilerplate of a new builtin. Mark the builtin as experimental at this time, allowing breaking changes in the near future, if necessary. Signed-off-by: Derrick Stolee Signed-off-by: Junio C Hamano

Merge branch 'ps/3.0-remote-deprecation'

2025-02-03T18:23:33Z

Following the procedure we established to introduce breaking changes for Git 3.0, allow an early opt-in for removing support of $GIT_DIR/branches/ and $GIT_DIR/remotes/ directories to configure remotes. * ps/3.0-remote-deprecation: remote: announce removal of "branches/" and "remotes/" builtin/pack-redundant: remove subcommand with breaking changes ci: repurpose "linux-gcc" job for deprecations ci: merge linux-gcc-default into linux-gcc Makefile: wire up build option for deprecated features