Re: Giving priority to the reftable topic (was Re: What's cooking in git.git (Aug 2021, #06; Mon, 16))

On Fri, Aug 20 2021, Ævar Arnfjörð Bjarmason wrote:

On Fri, Aug 20, 2021, 08:09 Junio C Hamano [off-list ref] wrote:

 Junio C Hamano [off-list ref] writes:

 > * hn/reftable (2021-08-16) 25 commits
 >  - t1404: annotate test cases with REFFILES
 >  ...
 >  - hash.h: provide constants for the hash IDs
 >
 >  The "reftable" backend for the refs API.

 As discussed in the thread that leads to [*1*], this topic has been
 blocked by the "clean-up errno use in the refs subsystem" topic for
 too long.  I think it deserves to have its own chance to be looked
 at by more eyes.

 I've reverted the three topics around "errno" out of 'next', while
 rebasing them into a single strand of pearls, and queued them near
 the tip of 'seen'.  The hn/reftable topic is merged into 'seen' 
 earlier then these "errno" topics.

 'seen' that has this topic, without merging known CI breakers (the
 three "errno" topics are known to break when they are with the
 hn/reftable topic, and the "builtin fsmonitor" also breaks CI),
 passes the usual tests [*2*], except for the "pedantic" test we
 recently added [*3*].

 The breakage flagged by the compiler are all:

         char *fn = get_tmp_template(__FUNCTION__);

 where the code expects that __FUNCTION__ is unconditionally
 available.

 With that problem fixed (which I would imagine should be easier than
 brain surgery), we should be able to move the topic lower in 'seen',
 hopefully touching 'next' soon to give it a wider exposure.

 And when hn/reftable gets stable enough, the "errno clean-up" topic
 can perhaps be rebased on top of it to work better together.

 Thanks.

(In the Gmail app, so this'll probably not make the list, sorry, feel free to quote it)

I've been on vacation for a couple of weeks, am back Monday.

I haven't been able to look at these breakages in detail but it looked like there was a fix-up plus a logic error in reftable in combination with it with
the now dead NULL parameter, perhaps something else I missed. I've only skimmed the list.

I had a subsequent fixup topic ready on top to remove that parameter, can include in in a reroll. Then the segfault will be caught at compile time via a
signature check.

As I noted on list before we can do it with reftable first if you'd like, but I don't think the end result will be easier to review or should be fast
tracked. We'll have the same questions about how reftable uses those ref APIs, but will need to review it against a basis that has more API action at a
distance.

So if you're willing to give me a few days I think d can sort it out to everyone's satisfaction with the refs API fixes first, if not I'll try to review
the reftable topic again, but will probably use a local merger of it and my topics as the basis for that.

I should have a re-roll of these topics ready soon, but aside from the
broken-ness of my "base" topics I don't see how the reftable topic is
anywhere near ready for "next" per my
https://lore.kernel.org/git/877dgch4rn.fsf@evledraar.gmail.com/ (local); whether
it's based on my "base" topics or not.

 [Reference]

 *1* https://lore.kernel.org/git/xmqqbl5syhiu.fsf@gitster.g/ (local)

 *2* https://github.com/git/git/actions/runs/1148914175

 *3* https://github.com/git/git/runs/3377289487?check_suite_focus=true#step:5:639