Re: [PATCH v5 0/8] you-still-use-that??: improve breaking changes troubleshooting

> 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.