{"thread":{"id":"52606","subject":"reftable progress","startedAt":"2020-01-09T19:16:31Z","lastAt":"2020-01-22T10:59:57Z","messageCount":5,"participants":["Han-Wen Nienhuys","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"389543","messageId":"CAFQ2z_OhNHauK_W1wL7WcOJnm2vCUGXLfYn_ZmLnt2rez+_TDw@mail.gmail.com","threadId":"52606","inReplyTo":null,"subject":"reftable progress","fromName":"Han-Wen Nienhuys","fromEmail":"hanwen@google.com","sentAt":"2020-01-09T19:16:14Z","receivedAt":"2020-01-09T19:16:31Z","isPatch":false,"sender":{"key":"hanwen@google.com","avatar":"https://avatars.githubusercontent.com/u/31547?v=4"},"body":"Hi folks,\n\nI have some alpha-quality code for Reftable support in Git at\n\n https://github.com/hanwen/git/tree/reftable\n\nI'd be curious for some feedback, both on the library\n(https://github.com/google/reftable) and the glue code in Git.\n\n-- \nHan-Wen Nienhuys - Google Munich\nI work 80%. Don't expect answers from me on Fridays.\n--\nGoogle Germany GmbH, Erika-Mann-Strasse 33, 80636 Munich\nRegistergericht und -nummer: Hamburg, HRB 86891\nSitz der Gesellschaft: Hamburg\nGeschäftsführer: Paul Manicle, Halimah DeLaine Prado\n"},{"id":"389547","messageId":"xmqq4kx4z8n3.fsf@gitster-ct.c.googlers.com","threadId":"52606","inReplyTo":"CAFQ2z_OhNHauK_W1wL7WcOJnm2vCUGXLfYn_ZmLnt2rez+_TDw@mail.gmail.com","subject":"Re: reftable progress","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-01-09T20:18:08Z","receivedAt":"2020-01-09T20:18:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Han-Wen Nienhuys <hanwen@google.com> writes:\n\n> Hi folks,\n>\n> I have some alpha-quality code for Reftable support in Git at\n>\n>  https://github.com/hanwen/git/tree/reftable\n>\n> I'd be curious for some feedback, both on the library\n> (https://github.com/google/reftable) and the glue code in Git.\n\nIf you are asking for feedback, sendign it over to this list with \n[RFC PATCH n/3]  as the subject prefix would have better chance.\n\nI have a feeling that the patch to show-ref is done at the wrong\nlevel.  The show_ref() function is given as the callback function\nto head_ref() and for_each_ref(), and the way these functions call\nthe callback function is part of the ref API.  \"In the reftable\nformat, ... are stored in the reference database too,\" is perfectly\nfine (that is the implementation detail of the ref API backend) but\n\"and are produced when iterating over the refs\" is not.  Hide that\ninside the ref API backend you are writing for reftable and this\nchange will become unnecessary.\n\nI agree with the general direction of the second patch that extends\nsetup.c to allow .git/refs to be a regular file to signal that the\nrepository is using reftable (instead of filesystem-based refs), but\nthe title \"fix repo detection\" is misleading---it is adjusting for\nthe new format (as there is nothing to \"fix\" if there weren't the\nnew format).  Also, the actual implementation may want to be a bit\nmore strict, i.e. saying \"we allow refs/ to be a searchable\ndirectory, and we also allow a readable regular file\".\n\nThanks.\n\n\n"},{"id":"390120","messageId":"CAFQ2z_PxumPGpgnTERcu3S+zdTj9PcVMKK9SjYxSDe3qW9q3jA@mail.gmail.com","threadId":"52606","inReplyTo":"xmqq4kx4z8n3.fsf@gitster-ct.c.googlers.com","subject":"Re: reftable progress","fromName":"Han-Wen Nienhuys","fromEmail":"hanwen@google.com","sentAt":"2020-01-20T18:22:54Z","receivedAt":"2020-01-20T18:23:10Z","isPatch":false,"sender":{"key":"hanwen@google.com","avatar":"https://avatars.githubusercontent.com/u/31547?v=4"},"body":"On Thu, Jan 9, 2020 at 9:18 PM Junio C Hamano <gitster@pobox.com> wrote:\n>\n> Han-Wen Nienhuys <hanwen@google.com> writes:\n>\n> > Hi folks,\n> >\n> > I have some alpha-quality code for Reftable support in Git at\n> >\n> >  https://github.com/hanwen/git/tree/reftable\n> >\n> > I'd be curious for some feedback, both on the library\n> > (https://github.com/google/reftable) and the glue code in Git.\n>\n> If you are asking for feedback, sendign it over to this list with\n> [RFC PATCH n/3]  as the subject prefix would have better chance.\n\nThanks, I'll look into that when I am done with my current TODO list.\n\nIn the meantime, I've updated the code at the above URL. The major\nmissing item is currently reflogs; hopefully I'll get to that next\nweek.\n\nI asked around, and it looks like we have slight preference for the\nBSD license (https://developers.google.com/open-source/licenses/bsd).\nAccording to the FSF, this is OK to combine with GPL software, so\nwould you be OK with that license?\n\nthanks,\n\n> I have a feeling that the patch to show-ref is done at the wrong\n> level.  The show_ref() function is given as the callback function\n> to head_ref() and for_each_ref(), and the way these functions call\n> the callback function is part of the ref API.  \"In the reftable\n> format, ... are stored in the reference database too,\" is perfectly\n> fine (that is the implementation detail of the ref API backend) but\n> \"and are produced when iterating over the refs\" is not.  Hide that\n> inside the ref API backend you are writing for reftable and this\n> change will become unnecessary.\n\nThe API is a little surprising here, because it means that an iterator\nshould always dereference a symref, regardless of storage format.\nSince it is not specific to the ref backend, this behavior should not\nbe in the ref backend code. But I've modified it now, and it seems to\nwork.\n\n-- \nHan-Wen Nienhuys - Google Munich\nI work 80%. Don't expect answers from me on Fridays.\n--\n\nGoogle Germany GmbH, Erika-Mann-Strasse 33, 80636 Munich\n\nRegistergericht und -nummer: Hamburg, HRB 86891\n\nSitz der Gesellschaft: Hamburg\n\nGeschäftsführer: Paul Manicle, Halimah DeLaine Prado\n"},{"id":"390189","messageId":"xmqqwo9kacac.fsf@gitster-ct.c.googlers.com","threadId":"52606","inReplyTo":"CAFQ2z_PxumPGpgnTERcu3S+zdTj9PcVMKK9SjYxSDe3qW9q3jA@mail.gmail.com","subject":"Re: reftable progress","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-01-21T18:34:51Z","receivedAt":"2020-01-21T18:34:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Han-Wen Nienhuys <hanwen@google.com> writes:\n\n> I asked around, and it looks like we have slight preference for the\n> BSD license (https://developers.google.com/open-source/licenses/bsd).\n> According to the FSF, this is OK to combine with GPL software, so\n> would you be OK with that license?\n\nSure, I think we are happy with adopting BSD code (and it would keep\nit more avaiable for other reimplementation of Git, which is good).\n\n> The API is a little surprising here, because it means that an iterator\n> should always dereference a symref, regardless of storage format.\n\nI do not think forcing the callers to dereference is clearly better\n(if so, we may want to consider changing the API to do so, but I do\nnot see such a strong reason).  Only when the vast majority of\ncallers would want just the name of the underlying ref without\nlearning the actual object value, such an optimization may make\nsense, but it would make the callers more difficult to write\ncorrectly (iow, somebody will forget to teach \"this is a symref, so\nwe need to ignore the incoming oid parameter and call read_ref()\nourselves to learn the name of the object\" to their each_ref_fn\ncallback functions, no?\n\n\n"},{"id":"390230","messageId":"CAFQ2z_OYF8ogmX-LMxL8LmbfK2C0bXUzGanSmStid9Rr4sf0nQ@mail.gmail.com","threadId":"52606","inReplyTo":"xmqqwo9kacac.fsf@gitster-ct.c.googlers.com","subject":"Re: reftable progress","fromName":"Han-Wen Nienhuys","fromEmail":"hanwen@google.com","sentAt":"2020-01-22T10:59:40Z","receivedAt":"2020-01-22T10:59:57Z","isPatch":false,"sender":{"key":"hanwen@google.com","avatar":"https://avatars.githubusercontent.com/u/31547?v=4"},"body":"On Tue, Jan 21, 2020 at 7:34 PM Junio C Hamano <gitster@pobox.com> wrote:\n> > I asked around, and it looks like we have slight preference for the\n> > BSD license (https://developers.google.com/open-source/licenses/bsd).\n> > According to the FSF, this is OK to combine with GPL software, so\n> > would you be OK with that license?\n>\n> Sure, I think we are happy with adopting BSD code (and it would keep\n> it more avaiable for other reimplementation of Git, which is good).\n\nYep. I'll go ahead with the license change then. Thanks!\n\n\n> > The API is a little surprising here, because it means that an iterator\n> > should always dereference a symref, regardless of storage format.\n>\n> I do not think forcing the callers to dereference is clearly better\n> (if so, we may want to consider changing the API to do so, but I do\n> not see such a strong reason).  Only when the vast majority of\n> callers would want just the name of the underlying ref without\n> learning the actual object value, such an optimization may make\n> sense, but it would make the callers more difficult to write\n> correctly (iow, somebody will forget to teach \"this is a symref, so\n> we need to ignore the incoming oid parameter and call read_ref()\n> ourselves to learn the name of the object\" to their each_ref_fn\n> callback functions, no?\n\nThere is an intermediate layer that wraps the refs/*-backend.c\nfunctions where this could be done.\n\n-- \nHan-Wen Nienhuys - Google Munich\nI work 80%. Don't expect answers from me on Fridays.\n--\n\nGoogle Germany GmbH, Erika-Mann-Strasse 33, 80636 Munich\n\nRegistergericht und -nummer: Hamburg, HRB 86891\n\nSitz der Gesellschaft: Hamburg\n\nGeschäftsführer: Paul Manicle, Halimah DeLaine Prado\n"}]}