Re: [PATCH v6 0/9] you-still-use-that??: improve breaking changes troubleshooting

From: Kristoffer Haugsbakk <code@khaugsbakk.name>
Date: Sep 18, 2025, 20:28 UTC
Message-ID: <c1392238-4869-4fcf-9d3d-5c7882167024@app.fastmail.com>
In-Reply-To: <20250918183117.GB1184978@coredump.intra.peff.net>

On Thu, Sep 18, 2025, at 20:31, Jeff King wrote:

Show 13 quoted lines

> 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!

Show 6 quoted lines

> 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