{"thread":{"id":"53735","subject":"Reftable progress","startedAt":"2020-06-22T22:03:48Z","lastAt":"2020-06-29T19:51:17Z","messageCount":3,"participants":["Han-Wen Nienhuys","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"400343","messageId":"CAFQ2z_NZbg4YoTo1vPaikfwYLMRZrx59bDMaeuczuJW2OG86DQ@mail.gmail.com","threadId":"53735","inReplyTo":null,"subject":"Reftable progress","fromName":"Han-Wen Nienhuys","fromEmail":"hanwen@google.com","sentAt":"2020-06-22T22:03:30Z","receivedAt":"2020-06-22T22:03:48Z","isPatch":false,"sender":{"key":"hanwen@google.com","avatar":"https://avatars.githubusercontent.com/u/31547?v=4"},"body":"Hi there,\n\nI wanted to give a few updates on reftable. I'm posting a new version\nof the patch series separately.  It has a number of interesting\nimprovements\n\n* The source in the git tree now uses the strbuf library, which was\nthe largest stumbling block for integration.\n\n*  The code is still completely self-contained (the\nREFTABLE_STANDALONE #define includes 100 lines worth of strbuf\ncompatible code; enough to run the unittests.)\n\n*  The number of test failures has dipped below 1000.\n\nI would like to post the next version on top of Phillip's patches that\nmake ref_xxx functions take a struct repository* argument. Is there a\nbranch that I can target for rebasing?\n\nThe bottom 2 commits should be OK to merge as is into next.\n(\"checkout: add '\\n' to reflog message\", \"lib-t6000.sh: write tag\nusing git-update-ref\")\n\nThe major open question is how to handle per-worktree refs.  My idea\nis that, on creation, the reftable backend can figure out if it is\nrunning in a worktree or in the main repository. If it is running in\nworktree X, we could read/write pseudorefs as ~X/PSEUDO_REF.\n\nCould we discuss next steps for merging at least the library? I think\nthat would solve one of the major complaints, which is that history is\nkept in a separate repository.\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":"400753","messageId":"CAFQ2z_Ohp29=Txu9ikn1i_GJQ8eYV9HNrKqSpAOMNamL92YZYQ@mail.gmail.com","threadId":"53735","inReplyTo":"CAFQ2z_NZbg4YoTo1vPaikfwYLMRZrx59bDMaeuczuJW2OG86DQ@mail.gmail.com","subject":"Re: Reftable progress","fromName":"Han-Wen Nienhuys","fromEmail":"hanwen@google.com","sentAt":"2020-06-29T18:57:15Z","receivedAt":"2020-06-29T18:57:39Z","isPatch":false,"sender":{"key":"hanwen@google.com","avatar":"https://avatars.githubusercontent.com/u/31547?v=4"},"body":"On Tue, Jun 23, 2020 at 12:03 AM Han-Wen Nienhuys <hanwen@google.com> wrote:\n> The bottom 2 commits should be OK to merge as is into next.\n> (\"checkout: add '\\n' to reflog message\", \"lib-t6000.sh: write tag\n> using git-update-ref\")\n\nThe patch t3432: use git-reflog to inspect the reflog for HEAD can\nalso be merged as is.\n\n> The major open question is how to handle per-worktree refs.  My idea\n> is that, on creation, the reftable backend can figure out if it is\n> running in a worktree or in the main repository. If it is running in\n> worktree X, we could read/write pseudorefs as ~X/PSEUDO_REF.\n\nI figured out a better way to do this. See the series that I am  posting today.\n\nTest failures are down to 556.\n\n> Could we discuss next steps for merging at least the library? I think\n> that would solve one of the major complaints, which is that history is\n> kept in a separate repository.\n\nanyone? Junio, Jonathan?\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":"400761","messageId":"xmqqr1txfy6v.fsf@gitster.c.googlers.com","threadId":"53735","inReplyTo":"CAFQ2z_Ohp29=Txu9ikn1i_GJQ8eYV9HNrKqSpAOMNamL92YZYQ@mail.gmail.com","subject":"Re: Reftable progress","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-06-29T19:51:04Z","receivedAt":"2020-06-29T19:51: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> On Tue, Jun 23, 2020 at 12:03 AM Han-Wen Nienhuys <hanwen@google.com> wrote:\n>> The bottom 2 commits should be OK to merge as is into next.\n>> (\"checkout: add '\\n' to reflog message\", \"lib-t6000.sh: write tag\n>> using git-update-ref\")\n>\n> The patch t3432: use git-reflog to inspect the reflog for HEAD can\n> also be merged as is.\n\nYeah, carving test updates in the early parts out of the series and\nhave them in 'next' and then in 'master' may make sense.  Good idea.\n\n>> The major open question is how to handle per-worktree refs.  My idea\n>> is that, on creation, the reftable backend can figure out if it is\n>> running in a worktree or in the main repository. If it is running in\n>> worktree X, we could read/write pseudorefs as ~X/PSEUDO_REF.\n>\n> I figured out a better way to do this. See the series that I am  posting today.\n\nIt seems that patches started trickling in but perhaps missing\npieces are mailspools somewhere and would arrive later?  I'll check\nthe list archive tomorrow to see if all 20 patches have arrived.\n\nThanks.\n"}]}