Re: Whatchanged

From: Anthony Clay <anthony.clay@masimo.com>
Date: Sep 3, 2025, 17:35 UTC
Message-ID: <BL3P221MB04497E3E6A13AEB178DD38F28301A@BL3P221MB0449.NAMP221.PROD.OUTLOOK.COM>
In-Reply-To: <20250830022718.GB567900@coredump.intra.peff.net>

Thanks for the response!

Talking with a few others here, we did discuss that the git config alias.* would be just fine.   Being able to override deprecated commands would be greatly preferred as my git config is already imported - so one and done, there.

________________________________________
From: Jeff King <peff@peff.net>
Sent: Friday, August 29, 2025 10:27 PM
To: Anthony Clay <anthony.clay@soundunited.com>
Cc: Kristoffer Haugsbakk <code@khaugsbakk.name>; git@vger.kernel.org <git@vger.kernel.org>
Subject: Re: Whatchanged
 
Message originated Externally.

On Fri, Aug 29, 2025 at 01:24:46PM +0000, Anthony Clay wrote:

Show 7 quoted lines

> Kernel audio driver maintainer, here. The first thing I want to know
> about a branch is "whatchanged" - it tells me exactly what I want to
> know with no distractions. So I was horrified when I saw the removal
> nomination message.  Please reconsider - while git log can do it, I
> don't use git log... at all. I'd just have to add another alias that
> would be another thing to constantly collide with while using docker
> build chains with different (but usually older) versions of git.

Aside from finger re-training, is there a reason that "git log --raw" doesn't work? It should work on all versions.

On the subject of finger re-training, you mentioned aliases, which made me think a bit. In a post-whatchanged world, you are free to do:

  git config alias.whatchanged "log --raw --no-merges"

Before then, that alias will be ignored. For older versions of Git, that's fine; the builtin does the same thing. But there's an awkward period _now_ where whatchanged complains about deprecation, but does not respect the alias.

I wonder if we should loosen the "aliases cannot override builtins" rule for deprecated commands. Perhaps something like the patch below.

That would let you configure that alias now, and everything would continue to work no matter which version of Git you used. Modulo the already-released ones with the deprecation warning but without the alias magic I'm suggesting. :( So maybe not quite as helpful as it could be, but something that could make deprecations less painful in general.

That said, I'm not sure from what you wrote above if it helps you or not. If your problem is that the containers have random unknown versions of Git, it would help in theory. But if your problem is that the containers do not have your alias config, then it is not much help.

-Peff

---

diff --git a/git.c b/git.c
index 5dc210b7b4..7c4b5a17a7 100644
--- a/git.c
+++ b/git.c
@@ -794,13 +794,32 @@ static void execv_dashed_external(const char **argv)
                exit(128);
 }

+static int is_deprecated_command(const char *cmd)
+{
+       return !strcmp(cmd, "whatchanged");
+}
+
 static int run_argv(struct strvec *args)
 {
        int done_alias = 0;
        struct string_list cmd_list = STRING_LIST_INIT_DUP;
        struct string_list_item *seen;

        while (1) {
+               /*
+                * Allow deprecated commands to be overridden by aliases. This
+                * creates a seamless path forward for people who want to keep
+                * using the name after it is gone, but want to skip the
+                * deprecation complaint in the meantime.
+                */
+               if (is_deprecated_command(args->v[0]) &&
+                   alias_lookup(args->v[0])) {
+                       if (!handle_alias(args))
+                               break;
+                       done_alias = 1;
+                       continue;
+               }
+
                /*
                 * If we tried alias and futzed with our environment,
                 * it no longer is safe to invoke builtins directly in