From: Kristoffer Haugsbakk Date: Thu, 18 Sep 2025 20:28:32 GMT Subject: Re: [PATCH v6 0/9] you-still-use-that??: improve breaking changes troubleshooting Message-ID: In-Reply-To: <20250918183117.GB1184978@coredump.intra.peff.net> On Thu, Sep 18, 2025, at 20:31, Jeff King wrote: > On Wed, Sep 17, 2025 at 10:24:10PM +0200, > kristofferhaugsbakk@fastmail.com wrote: > >> § Changes in v6 >> >> Use Peff’s patch to get rid of “the extra output”.[1] Update commit >> messages to not mention that. >> >> Also use another fix from Peff (patch 1); don’t list git-whatchanged(1) >> as a builtin when `WITH_BREAKING_CHANGES`. > > Thanks, I looked over the patches that touch the things we've been > discussing, and it all looks good to me. Thanks for the review! > I am a little troubled that even after your patch 1, the test suite will > get confused by a stray git-whatchanged binary left over from an earlier > build. That may become an irritation later, when the breaking change > becomes the norm. But maybe it won't be too bad. At that point the > matching entry in .gitignore should be dropped, so at least "git clean" > will find it. Yeah this seems tricky. And this in-between space seems difficult to deal with even with all the tools like gitignore and whatnot. > In the meantime, building with and without the breaking-changes flag > can cause confusion, but presumably people aren't swapping between > them too often? I for one (and honestly) only did it now when I was informed that it failed the test. I’ll keep it confined in its own worktree where I have no qualms doing git-clean(1) every run. > And I don't have a clever idea of how > to do better, short of having the breaking-changes flag explicitly > delete git-whatchanged from the build directory. Which feels a little > gross. Not that I know anything about build systems but that doesn’t sound like a bad or unprincipled solution. > So I'd say to call it good for now, and if it comes back to bite us > later, it is not harder to address then than it would be now. -- Kristoffer