Re: Failing tests with WITH_BREAKING_CHANGES

Phillip Wood <[email protected]> Wed, 29 Jul 2026 16:25:42 +0100
Newsgroups org.kernel.vger.git
Message-ID <[email protected]>
On 28/07/2026 14:55, Jeff King wrote:
> On Tue, Jul 28, 2026 at 02:31:03PM +0100, Phillip Wood wrote:
> 
>> 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
>