Re: What's cooking in git.git (Jan 2025, #09; Fri, 31)

From: Karthik Nayak <karthik.188@gmail.com>
Date: Feb 4, 2025, 10:07 UTC
Message-ID: <CAOLa=ZSoiEeJqP8GDdyStOjNaw6itAHjJH=t28jp1tssjAun5Q@mail.gmail.com>
In-Reply-To: <xmqq5xlu4bt6.fsf@gitster.g>

Junio C Hamano <gitster@pobox.com> writes:

[snip]

Show 12 quoted lines

> * kn/reflog-migration-fix (2025-01-15) 1 commit
>   (merged to 'next' on 2025-01-16 at ae8f9ce9a0)
>  + reftable: write correct max_update_index to header
>  (this branch is used by kn/reflog-migration-fix-fix and kn/reflog-migration-fix-followup.)
>
>  "git refs migrate" for migrating reflog data was broken.
>
>  On hold.
>  cf. <Z4mUizLNUdq_1BgY@tapette.crustytoothpaste.net>
>  cf. <CAOLa=ZT4nws0irdZKUuWc70Rv9RUNQuSXnGAt1SnE1O+umSReg@mail.gmail.com>
>  source: <CAOLa=ZTL9n_DPhNr49XAd6bT838kc09oVx_AH7Pb4o8VK_xQ9w@mail.gmail.com>
>

There was some discussion around Coverity [1] on this series. But the conclusion was that this (all instances of not checking the return code of `check()` in our unit tests) would be fixed when the unit tests are migrated to the clar framework.

Apart from that, there was a Nit suggested by Patrick [2]. Which also is a broader cleanup and can be done as a part of a later patch as #leftoverbits.

So all in all, this can be moved from 'on hold'.

As for a brief about the topic, perhaps:

    Additional safeguards to prevent 'update_index' changes post record
    additions in the reftable backend and small cleanups alongside.

[1]: https://lore.kernel.org/git/20250201022409.GA4082344@coredump.intra.peff.net/ [2]: https://lore.kernel.org/git/Z5DgxQuc2j_-5GHg@pks.im/