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

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

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

> On Fri, Aug 20, 2021, 08:09 Junio C Hamano <gitster@pobox.com> wrote:
>
>  Junio C Hamano <gitster@pobox.com> 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/; whether
it's based on my "base" topics or not.

>  [Reference]
>
>  *1* https://lore.kernel.org/git/xmqqbl5syhiu.fsf@gitster.g/
>
>  *2* https://github.com/git/git/actions/runs/1148914175
>
>  *3* https://github.com/git/git/runs/3377289487?check_suite_focus=true#step:5:639