Dear git maintainers,
I am using "git whatchanged" on a regular basis to understand what files specific commits touched and in what way. I vote for not removing this functionality from git.
Many thanks, Franz Brauße
Dear git maintainers,
I am using "git whatchanged" on a regular basis to understand what files specific commits touched and in what way. I vote for not removing this functionality from git.
Many thanks, Franz Brauße
Re: git whatchanged
On Fri, Nov 7, 2025, at 12:40, Franz Brauße wrote:
> I am using "git whatchanged" on a regular basis to understand what > files specific commits touched and in what way.
This command is being removed because it was supplanted by git-log(1) a long while ago. Both commands use the same machinery, just with different defaults.
You can replace it with `git log` in this way:
• Given: `git whatchanged <opts>` • Replace with: `git log <opts> --no-merges --raw`
Additionally for the sake of readability, you might have more use for `--stat` or `--name-only` rather than `--raw` if you are only reading the output (not feeding the output to another program).
> I vote for not removing this functionality from git.
The intent behind the message was not to cast a vote but I can totally understand it being read that way.
See: https://git-scm.com/docs/BreakingChanges
-- Kristoffer Haugsbakk
Re: git whatchanged
On Fri, 07 Nov 2025 14:11:52 +0100 "Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> wrote:
> This command is being removed because it was supplanted by git-log(1) a > long while ago. Both commands use the same machinery, just with > different defaults. > > You can replace it with `git log` in this way: > [snip] > See: https://git-scm.com/docs/BreakingChanges
Thank you for the additional infos and the link, I didn't know that! I suppose when it's being removed, I can resurrect the "whatchanged" subcommand via the config's alias mechanism (git wh<TAB> is just baked into my fingers at the moment).
Might I suggest that for future deprecations instead of an annoying to type flag just a message like "this command is scheduled for removal in v<VERSION>, see <URL>; use "git log --raw --no-merges" for similar functionality" is printed in addition to the command still working as before while it's there? Similar to how "git pull" informs users about the rebase vs. merge options in case of diverged branches?
Anyhow, thanks again for all your work on this extremely nice tool!
Franz
Re: git whatchanged
On Fri, Nov 7, 2025, at 15:16, Franz Brauße wrote:
> On Fri, 07 Nov 2025 14:11:52 +0100 "Kristoffer Haugsbakk" >>[snip] > > Thank you for the additional infos and the link, I didn't know that! I > suppose when it's being removed, I can resurrect the "whatchanged" > subcommand via the config's alias mechanism (git wh<TAB> is just baked > into my fingers at the moment).
You can set up an alias with that name on Git 2.51.1 and 2.51.2 today. (And later Git 2.52.0 (soon to be released).)
git config set --global alias.whatchanged 'log --raw --no-merges'
You cannot do that on Git 2.51.0 since you cannot alias builtin commands. But you can alias deprecated builtin commands on those versions.
> Might I suggest that for future deprecations instead of an annoying to > type flag just a message like "this command is scheduled for removal in > v<VERSION>, see <URL>; use "git log --raw --no-merges" for similar > functionality"
This is the current error message on Git 2.51.1 and later:
$ git whatchanged
'git whatchanged' is nominated for removal. hint: You can replace 'git whatchanged <opts>' with:
hint: git log <opts> --raw --no-merges
hint: Or make an alias:
hint: git config set --global alias.whatchanged 'log --raw --no-merges'If you still use this command, here's what you can do:
- read https://git-scm.com/docs/BreakingChanges.html
- check if anyone has discussed this on the mailing
list and if they came up with something that can
help you: https://lore.kernel.org/git/?q=git%20whatchanged
- send an email to <git@vger.kernel.org> to let us
know that you still use this command and were unable
to determine a suitable replacement> for future deprecations [...] is printed in addition to the command > still working as before while it's there? Similar to how "git pull" > informs users about the rebase vs. merge options in case of diverged > branches?
The thing about git-whatchanged(1) is that it has been deprecated for twelve years according to the man page. But the man page didn’t explicitly say “deprecated” in 2.51.0 and earlier. But that seems to have been the intent. (Now it says explicitly that in the man page on 2.51.1 and later.)
This `--i-still-use-this` thing was only implemented (to the best of my knowledge) for commands and functionality that have already been deprecated for a long time. So it will not be used for fresh deprecations.
> > Anyhow, thanks again for all your work on this extremely nice tool!