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 >