On 2026-07-28 at 14:38:45, Jeff King wrote:
> We have a few tests related to aliasing of deprecated commands. They use
> whatchanged and pack-redundant because those are the only two deprecated
> commands we have. Eventually those commands will be removed, at which
> point these tests will be checking nothing useful (they'll just be
> regular aliases, which we already cover in other tests).
> 
> We could remove them at that point, but the code to handle deprecated
> commands will still remain. We probably do want to keep the tests around
> for the eventual day that we deprecate more commands. So let's ask Git
> for its list of deprecated commands, and if we don't have any, skip
> those tests.
> 
> This also prevents an annoying corner case when your build directory
> contains old build products. Right now those commands are marked as
> deprecated builtins and treated specially; we allow aliases and never
> look for them as dashed external commands. But after they are removed,
> they aren't special anymore. If your directory happens to contain
> hardlinks from the build of an older version, that confuses Git: it sees
> the old hardlinks in place, thinks those are actual external commands,
> and refuses to allow aliasing.
> 
> You can see that today like this:
> 
>   make
>   make WITH_BREAKING_CHANGES=1 test
> 
> The first "make" creates git-whatchanged as a hardlink to Git, and the
> second does not clean it up (it doesn't know about the whatchanged
> command at all anymore). t0014 fails because Git won't create an alias
> to the "external" whatchanged command.

These patches look sensible.  I was planning to spend some time this
morning investigating more since I woke up early, but I appreciate you
sending some patches in to fix them.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA