Re: reftable progress
- From
Han-Wen Nienhuys <hanwen@google.com>
- Date
- Jan 22, 2020, 10:59 UTC
- Message-ID
- <CAFQ2z_OYF8ogmX-LMxL8LmbfK2C0bXUzGanSmStid9Rr4sf0nQ@mail.gmail.com>
- In-Reply-To
- <xmqqwo9kacac.fsf@gitster-ct.c.googlers.com>
On Tue, Jan 21, 2020 at 7:34 PM Junio C Hamano <gitster@pobox.com> wrote:
Show 7 quoted lines
> > 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!
Show 13 quoted lines
> > 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