From: Jeff King <peff@peff.net>
Date: Tue, 16 Sep 2025 23:24:46 GMT
Subject: Re: [PATCH v5 0/8] you-still-use-that??: improve breaking changes troubleshooting
Message-ID: <20250916232446.GA1189675@coredump.intra.peff.net>
In-Reply-To: <e4fc3b83-15ca-4844-92c6-1f41169161ed@app.fastmail.com>

On Tue, Sep 16, 2025 at 10:47:58PM +0200, Kristoffer Haugsbakk wrote:

> Thanks.  This is (maybe you surmise or know already but) a
> problem when on the branch itself as well.  I did some compiling
> `WITH_BREAKING_CHANGES=YesPlease` and it seems that 07572f220a8
> (whatchanged: remove when built with WITH_BREAKING_CHANGES, 2025-05-12)
> made it a hard error to call `whatchanged` after its death:
> 
>     $ ./bin-wrappers/git whatchanged
>     fatal: cannot handle whatchanged as a builtin
> 
> This seems fine, although I would have expected it to say something more
> neutral like “command not found”.

I think the breaking-changes code for whatchanged did not update the
Makefile appropriately. If I build with that flag:

  [make sure it is not here]
  $ rm git-whatchanged

  [now build]
  $ make WITH_BREAKING_CHANGES=YesPlease
    [...]
    BUILTIN git-whatchanged
    SUBDIR templates

  $ ls -l git-whatchanged
  -rwxrwxr-x 140 peff peff 12104368 Sep 16 19:15 git-whatchanged*

So we have linked it in the usual way we do for builtins, so that
git-whatchanged would "work". But of course since it is not in the
builtin table, it does not:

  $ ./git-whatchanged
  fatal: cannot handle whatchanged as a builtin

And then because it exists in the exec-path, "git whatchanged" thinks
that it can run the dashed form, so it produces the same message.

We probably need this:

diff --git a/Makefile b/Makefile
index e11340c1ae..9311da5bb1 100644
--- a/Makefile
+++ b/Makefile
@@ -883,7 +883,9 @@ BUILT_INS += git-stage$X
 BUILT_INS += git-status$X
 BUILT_INS += git-switch$X
 BUILT_INS += git-version$X
+ifndef WITH_BREAKING_CHANGES
 BUILT_INS += git-whatchanged$X
+endif
 
 # what 'all' will build but not install in gitexecdir
 OTHER_PROGRAMS += git$X

but annoyingly an old build will leave git-whatchanged in place and
cause the same confusion. And git-status won't even notice that it's
leftover because .gitignore mentions it. But we can't drop it from
.gitignore until the non-breaking-changes builds go away entirely. Yuck.

> What I don’t understand though is this:
> 
>     $ ./bin-wrappers/git -c alias.whatchanged=status whatchanged
>     fatal: cannot handle whatchanged as a builtin
> 
> People have been saying that people can at least alias `whatchanged` to
> `log <something>` and then it will work after the removal.  But now that
> it has been removed (according to the commit message) its spirit lives
> on and prevents reusing the name?

I'd have thought the alias took precedence over the stale executable
file. But it can't, because "whatchanged" is no longer marked as
deprecated in the builtin list. Because it's not in the builtin list at
all! So it is just a "normal" non-deprecated external command from the
perspective of git.c, and you are not allowed to override it.

So I think the alias code is working as expected, but the stale file is
causing the same confusion as above. Deleting it makes everything work.

-Peff