Re: What's cooking in git.git (Sep 2025, #06; Mon, 15)

From: Jeff King <peff@peff.net>
Date: Sep 16, 2025, 16:49 UTC
Message-ID: <20250916164912.GA15474@coredump.intra.peff.net>
In-Reply-To: <xmqqzfaunzjo.fsf@gitster.g>

On Tue, Sep 16, 2025 at 09:16:11AM -0700, Junio C Hamano wrote:

Show 19 quoted lines

> As this makes it necessary for that file to eventually include an
> extra header, it sort of makes sense.  I am more wondering if it
> should be a separate commit (i.e. give it a proper log message
> instead of fixup!).  If we were to squash, we would need to mention
> why a seemingly unnecessary change is included.  "In anticipation of
> another topic that adds a call to function Y, whose definition this
> topic shuffles around and makes it necessary for its callers to
> include header X, we pre-emptively include header X that will become
> needed for the other topic to use function Y when merged with this
> topic".  I agree that is certainly awkward.
> 
> Adding the extra include to the other topic is not any cleaner.  It
> didn't have to include that header to make calls to some functions,
> and it is only because another topic shuffled things around that
> made it necessary.  "In anticipation of another topic shuffling
> headers around, we pre-emptively include header X that will become
> needed to use function Y when merged with the other topic" would be
> such an extra commit would say.  That may be slightly less awkward
> but it still is so.

I think adding the fix to ps/packfile-store is reasonably clean. It is subtly depending on a header file having included repository.h, and that assumption is broken by the other topic. But it was always a slightly dubious assumption.

That said, it is not really that big an issue and I am fine with any fix. If you want to document how the history unfolded, then I think an evil merge shows that (neither topic had a problem on its own, but when merged we needed to adjust the result). And it is probably the least amount of work. ;)

-Peff