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

References: <xmqqv945ng61.fsf@gitster.g> <xmqqtujkwsu0.fsf@gitster.g>
User-agent: Debian GNU/Linux 11 (bullseye); Emacs 27.1; mu4e 1.5.13
In-reply-to: <xmqqtujkwsu0.fsf@gitster.g>

On Thu, Aug 19 2021, Junio C Hamano wrote:

Junio C Hamano [off-list ref] writes:

quoted

* 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.


[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

I sent the following yesterday in the GMail mobile app as
[off-list ref], I
did not have laptop access (vacation, back now), so it was rejected due
to inline HTML. Re-sending it here for the list's benefit:
    
    (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 hadn't seen c128427fd74 (Revert hn/refs-errno-cleanup and related
topics, 2021-08-19) yet, but in any case, I'll look at the breakages
etc. and see what can be done about them. Sorry for the
non-responsiveness for the last 2 weeks.