threads / discuss / 53735

Reftable progress

Subject: Reftable progress

## tl;dr

3 messages between Jun 22, 2020 and Jun 29, 2020.

replies: 2people: 2as markdown or json

Han-Wen Nienhuys· Jun 22, 2020, 22:03 UTC · lore

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· Jun 29, 2020, 18:57 UTC · re: Han-Wen Nienhuys · lore

Re: Reftable progress

On Tue, Jun 23, 2020 at 12:03 AM Han-Wen Nienhuys <hanwen@google.com> 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· Jun 29, 2020, 19:51 UTC · re: Han-Wen Nienhuys · lore

Re: Reftable progress

Han-Wen Nienhuys <hanwen@google.com> writes:

Show 7 quoted lines

> On Tue, Jun 23, 2020 at 12:03 AM Han-Wen Nienhuys <hanwen@google.com> 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.

Show 6 quoted lines

>> 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.