Re: Failing tests with WITH_BREAKING_CHANGES

On 28/07/2026 14:55, Jeff King wrote:

On Tue, Jul 28, 2026 at 02:31:03PM +0100, Phillip Wood wrote:

quoted

I find t1517 fails quite often for me due to cruft from a previous build
when a different branch was checked out. I wonder if there is a command that
is no-longer built by WITH_BREAKING_CHANGES whose executable still exists in
the build directory from a previous build. Its not clear to me why the alias
tests might be failing though.

It's the same reason. We test looping through deprecated aliases using
whatchanged and pack-redundant. When those are builtin but deprecated
(like now) we allow aliases. After the breaking-changes split, those
names are not special at all, and they are subject to the usual alias
rules. If there is crufty git-whatchanged in your build directory, then
that is an "external command" unknown to Git and you are not allowed to
alias over it.

Oh, of course - thanks for explaining that. Thanks for fixing the tests 
as well, I've only skimmed them but they seemed to make sense.

Phillip

The test in t0014 that covers this should be removed after the breaking
changes actually land (those commands won't handled specially, so it's
not different than the normal alias loop detection).

But we are in a funny limbo now for WITH_BREAKING_CHANGES. Possibly we
could pull the value out of GIT-BUILD-OPTIONS (which I guess happens
already via the environment) and use a prereq to skip the test.

-Peff