# reftable progress 5 messages from 2020-01-09 to 2020-01-22. Participants: Han-Wen Nienhuys, Junio C Hamano. Thread: https://gitlist.dev/t/52606 ## Han-Wen Nienhuys, 2020-01-09 19:16 Subject: reftable progress Message-ID: URL: https://gitlist.dev/e/CAFQ2z_OhNHauK_W1wL7WcOJnm2vCUGXLfYn_ZmLnt2rez%2B_TDw%40mail.gmail.com ``` 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 - 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 ``` ## Junio C Hamano, 2020-01-09 20:18 Subject: Re: reftable progress Message-ID: URL: https://gitlist.dev/e/xmqq4kx4z8n3.fsf%40gitster-ct.c.googlers.com In-Reply-To: ``` Han-Wen Nienhuys writes: > 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. ``` ## Han-Wen Nienhuys, 2020-01-20 18:22 Subject: Re: reftable progress Message-ID: URL: https://gitlist.dev/e/CAFQ2z_PxumPGpgnTERcu3S%2BzdTj9PcVMKK9SjYxSDe3qW9q3jA%40mail.gmail.com In-Reply-To: ``` On Thu, Jan 9, 2020 at 9:18 PM Junio C Hamano wrote: > > Han-Wen Nienhuys writes: > > > 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. 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, > 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. 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 - 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 ``` ## Junio C Hamano, 2020-01-21 18:34 Subject: Re: reftable progress Message-ID: URL: https://gitlist.dev/e/xmqqwo9kacac.fsf%40gitster-ct.c.googlers.com In-Reply-To: ``` Han-Wen Nienhuys writes: > 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? 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). > The API is a little surprising here, because it means that an iterator > should always dereference a symref, regardless of storage format. 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? ``` ## Han-Wen Nienhuys, 2020-01-22 10:59 Subject: Re: reftable progress Message-ID: URL: https://gitlist.dev/e/CAFQ2z_OYF8ogmX-LMxL8LmbfK2C0bXUzGanSmStid9Rr4sf0nQ%40mail.gmail.com In-Reply-To: ``` On Tue, Jan 21, 2020 at 7:34 PM Junio C Hamano wrote: > > 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? > > 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). Yep. I'll go ahead with the license change then. Thanks! > > The API is a little surprising here, because it means that an iterator > > should always dereference a symref, regardless of storage format. > > 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? There is an intermediate layer that wraps the refs/*-backend.c functions where this could be done. -- 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 ```