Re: reftable progress

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 9, 2020, 20:18 UTC
Message-ID: <xmqq4kx4z8n3.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <CAFQ2z_OhNHauK_W1wL7WcOJnm2vCUGXLfYn_ZmLnt2rez+_TDw@mail.gmail.com>

Han-Wen Nienhuys <hanwen@google.com> writes:

Show 8 quoted lines

> Hi folks,
>
> I have some alpha-quality code for Reftable support in Git at
>
>  https://github.com/hanwen/git/tree/reftable
>
> I'd be curious for some feedback, both on the library
> (https://github.com/google/reftable) and the glue code in Git.

If you are asking for feedback, sendign it over to this list with [RFC PATCH n/3] as the subject prefix would have better chance.

I have a feeling that the patch to show-ref is done at the wrong level. The show_ref() function is given as the callback function to head_ref() and for_each_ref(), and the way these functions call the callback function is part of the ref API. "In the reftable format, ... are stored in the reference database too," is perfectly fine (that is the implementation detail of the ref API backend) but "and are produced when iterating over the refs" is not. Hide that inside the ref API backend you are writing for reftable and this change will become unnecessary.

I agree with the general direction of the second patch that extends setup.c to allow .git/refs to be a regular file to signal that the repository is using reftable (instead of filesystem-based refs), but the title "fix repo detection" is misleading---it is adjusting for the new format (as there is nothing to "fix" if there weren't the new format). Also, the actual implementation may want to be a bit more strict, i.e. saying "we allow refs/ to be a searchable directory, and we also allow a readable regular file".

Thanks.