On Fri, Aug 20 2021, Ævar Arnfjörð Bjarmason wrote: > On Fri, Aug 20, 2021, 08:09 Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Junio C Hamano <gitster@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx/; 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
