# Reftable progress 3 messages from 2020-06-22 to 2020-06-29. Participants: Han-Wen Nienhuys, Junio C Hamano. Thread: https://gitlist.dev/t/53735 ## Han-Wen Nienhuys, 2020-06-22 22:03 Subject: Reftable progress Message-ID: URL: https://gitlist.dev/e/CAFQ2z_NZbg4YoTo1vPaikfwYLMRZrx59bDMaeuczuJW2OG86DQ%40mail.gmail.com ``` Hi there, I wanted to give a few updates on reftable. I'm posting a new version of the patch series separately. It has a number of interesting improvements * The source in the git tree now uses the strbuf library, which was the largest stumbling block for integration. * The code is still completely self-contained (the REFTABLE_STANDALONE #define includes 100 lines worth of strbuf compatible code; enough to run the unittests.) * The number of test failures has dipped below 1000. I would like to post the next version on top of Phillip's patches that make ref_xxx functions take a struct repository* argument. Is there a branch that I can target for rebasing? The bottom 2 commits should be OK to merge as is into next. ("checkout: add '\n' to reflog message", "lib-t6000.sh: write tag using git-update-ref") The major open question is how to handle per-worktree refs. My idea is that, on creation, the reftable backend can figure out if it is running in a worktree or in the main repository. If it is running in worktree X, we could read/write pseudorefs as ~X/PSEUDO_REF. Could we discuss next steps for merging at least the library? I think that would solve one of the major complaints, which is that history is kept in a separate repository. -- 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 ``` ## Han-Wen Nienhuys, 2020-06-29 18:57 Subject: Re: Reftable progress Message-ID: URL: https://gitlist.dev/e/CAFQ2z_Ohp29%3DTxu9ikn1i_GJQ8eYV9HNrKqSpAOMNamL92YZYQ%40mail.gmail.com In-Reply-To: ``` On Tue, Jun 23, 2020 at 12:03 AM Han-Wen Nienhuys wrote: > The bottom 2 commits should be OK to merge as is into next. > ("checkout: add '\n' to reflog message", "lib-t6000.sh: write tag > using git-update-ref") The patch t3432: use git-reflog to inspect the reflog for HEAD can also be merged as is. > The major open question is how to handle per-worktree refs. My idea > is that, on creation, the reftable backend can figure out if it is > running in a worktree or in the main repository. If it is running in > worktree X, we could read/write pseudorefs as ~X/PSEUDO_REF. I figured out a better way to do this. See the series that I am posting today. Test failures are down to 556. > Could we discuss next steps for merging at least the library? I think > that would solve one of the major complaints, which is that history is > kept in a separate repository. anyone? Junio, Jonathan? -- 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-06-29 19:51 Subject: Re: Reftable progress Message-ID: URL: https://gitlist.dev/e/xmqqr1txfy6v.fsf%40gitster.c.googlers.com In-Reply-To: ``` Han-Wen Nienhuys writes: > On Tue, Jun 23, 2020 at 12:03 AM Han-Wen Nienhuys wrote: >> The bottom 2 commits should be OK to merge as is into next. >> ("checkout: add '\n' to reflog message", "lib-t6000.sh: write tag >> using git-update-ref") > > The patch t3432: use git-reflog to inspect the reflog for HEAD can > also be merged as is. Yeah, carving test updates in the early parts out of the series and have them in 'next' and then in 'master' may make sense. Good idea. >> The major open question is how to handle per-worktree refs. My idea >> is that, on creation, the reftable backend can figure out if it is >> running in a worktree or in the main repository. If it is running in >> worktree X, we could read/write pseudorefs as ~X/PSEUDO_REF. > > I figured out a better way to do this. See the series that I am posting today. It seems that patches started trickling in but perhaps missing pieces are mailspools somewhere and would arrive later? I'll check the list archive tomorrow to see if all 20 patches have arrived. Thanks. ```