reftable progress

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.

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

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.

On Thu, Jan 9, 2020 at 9:18 PM Junio C Hamano <gitster@pobox.com> wrote:

Thanks, I'll look into that when I am done with my current TODO list.

In the meantime, I've updated the code at the above URL. The major missing item is currently reflogs; hopefully I'll get to that next week.

I asked around, and it looks like we have slight preference for the BSD license (https://developers.google.com/open-source/licenses/bsd). According to the FSF, this is OK to combine with GPL software, so would you be OK with that license?

thanks,

The API is a little surprising here, because it means that an iterator should always dereference a symref, regardless of storage format. Since it is not specific to the ref backend, this behavior should not be in the ref backend code. But I've modified it now, and it seems to work.

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

Sure, I think we are happy with adopting BSD code (and it would keep it more avaiable for other reimplementation of Git, which is good).

I do not think forcing the callers to dereference is clearly better (if so, we may want to consider changing the API to do so, but I do not see such a strong reason). Only when the vast majority of callers would want just the name of the underlying ref without learning the actual object value, such an optimization may make sense, but it would make the callers more difficult to write correctly (iow, somebody will forget to teach "this is a symref, so we need to ignore the incoming oid parameter and call read_ref() ourselves to learn the name of the object" to their each_ref_fn callback functions, no?

On Tue, Jan 21, 2020 at 7:34 PM Junio C Hamano <gitster@pobox.com> wrote:

Yep. I'll go ahead with the license change then. Thanks!

There is an intermediate layer that wraps the refs/*-backend.c functions where this could be done.