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

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.


[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

On 20/08/2021 07:09, 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.

Just a gentle reminder that this topic tickles my 'static-check.pl'
script, like so:

  $ diff nsc ssc
  ...
  88a91,98
  > reftable/generic.o	- reftable_table_seek_log
  > reftable/merged.o	- reftable_merged_table_hash_id
  > reftable/merged.o	- reftable_merged_table_min_update_index
  > reftable/merged.o	- reftable_merged_table_seek_log_at
  > reftable/publicbasics.o	- reftable_set_alloc
  > reftable/reader.o	- reader_seek
  > reftable/reader.o	- reftable_reader_seek_log_at
  > reftable/stack.o	- reftable_stack_auto_compact
  ...
  $ 

Which is to say, all of the above symbols are defined (and called) in
the '.c' file corresponding to the given object file, but not called
anywhere outside that file. I have not even looked at those functions,
but (with the possible exception of reftable_set_alloc()) they don't
strike me as 'public API functions'. So, maybe they should be marked
as 'static'?

ATB,
Ramsay Jones

On Sat, Aug 21, 2021 at 12:08 AM Ramsay Jones
[off-list ref] wrote:

Just a gentle reminder that this topic tickles my 'static-check.pl'
script, like so:

  $ diff nsc ssc
  ...
  88a91,98
  > reftable/generic.o  - reftable_table_seek_log
  > reftable/merged.o   - reftable_merged_table_hash_id
  > reftable/merged.o   - reftable_merged_table_min_update_index
  > reftable/merged.o   - reftable_merged_table_seek_log_at
  > reftable/publicbasics.o     - reftable_set_alloc
  > reftable/reader.o   - reader_seek
  > reftable/reader.o   - reftable_reader_seek_log_at
  > reftable/stack.o    - reftable_stack_auto_compact
  ...
  $

Which is to say, all of the above symbols are defined (and called) in
the '.c' file corresponding to the given object file, but not called
anywhere outside that file. I have not even looked at those functions,
but (with the possible exception of reftable_set_alloc()) they don't
strike me as 'public API functions'. So, maybe they should be marked
as 'static'?

They're all public except reader_seek().
I added some more coverage, in v4 of the library topic.

--
Han-Wen Nienhuys - Google Munich
I work 80%. Don't expect answers from me on Fridays.
--

Google Germany GmbH, Erika-Mann-Strasse 33, 80636 Munich

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado