On Tue, Feb 1, 2022 at 11:12 PM Junio C Hamano [off-list ref] wrote:

Ævar Arnfjörð Bjarmason [off-list ref] writes:

quoted

We could surely add magic record types, but how would such a dance be
performed while keeping compatibility with existing JGit clients?

Yes.  It is exactly the point of the question I asked.  If it is
simple and easy to add such a new type that is ignored/skipped by
existing clients, then we can go that route.  If it is simple and
easy to add a new bit per ref that existing clients would not barf,
we can use that as an alternative implementation strategy.

I'm not sure that there are any JGit clients: I committed reftable
support at the end of 2019. Before that time, we were running it
internally at Google, but only ref storage, and without the posix
part. Reflogs were never stored in refable, and I actually found a
couple of bugs in Shawn's Java code.

Gerrit has increasingly started using Git as a database, and the
packed/loose system is just not a very good database, so that
motivates the work reftable in general. But the folks who run Gerrit
on a POSIX filesystem want to be sure that isn't a fringe feature, so
they only want to start using it once Git itself supports it. So there
is a chicken & egg problem.

It's sad that we have to introduce an existence bit to make things
work, but overall it is probably easier for me to do than trying to
make sense of sequencer.c and how it uses refs/stash@{0}.

Technically, the only obstacle I see is that we'd need to treat an
existence entry especially for the purpose of compaction/gc: we can
discard older entries, but we shouldn't discard the existence bit, no
matter how old it is.

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