git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 2/3] t1405: mark test that checks existence as REFFILES

From
Han-Wen Nienhuys <hanwen@google.com>
Date
Feb 3, 2022, 16:02 UTC
Message-ID
<CAFQ2z_NSCvRbj1bxirxhqSWD+LadzCa8VNOsxGCmFCNT3GUU0g@mail.gmail.com>
In-Reply-To
<xmqqsft2b5jl.fsf@gitster.g>
On Tue, Feb 1, 2022 at 11:12 PM Junio C Hamano <gitster@pobox.com> wrote:
Show 11 quoted lines
>
> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
> > 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
Previous: Junio C HamanoNext: Ævar Arnfjörð Bjarmason
Message 10 of 21 in “reftable related test tweaks”
  1. 0/3 reftable related test tweaksHan-Wen Nienhuys via GitGitGadget, Jan 31, 2022
  2. 1/3 t1405: explictly delete reflogs for reftableHan-Wen Nienhuys via GitGitGadget, Jan 31, 2022
  3. 2/3 t1405: mark test that checks existence as REFFILESHan-Wen Nienhuys via GitGitGadget, Jan 31, 2022
  4. Taylor BlauJan 31, 2022
  5. Junio C HamanoJan 31, 2022
  6. Han-Wen NienhuysFeb 1, 2022
  7. Junio C HamanoFeb 1, 2022
  8. Ævar Arnfjörð BjarmasonFeb 1, 2022
  9. Junio C HamanoFeb 1, 2022
  10. Han-Wen NienhuysFeb 3, 2022
  11. Ævar Arnfjörð BjarmasonFeb 3, 2022
  12. Han-Wen NienhuysFeb 3, 2022
  13. Junio C HamanoFeb 3, 2022
  14. Han-Wen NienhuysFeb 7, 2022
  15. Han-Wen NienhuysFeb 7, 2022
  16. Junio C HamanoFeb 7, 2022
  17. Han-Wen NienhuysFeb 8, 2022
  18. 3/3 t5312: prepare for reftableHan-Wen Nienhuys via GitGitGadget, Jan 31, 2022
  19. Ævar Arnfjörð BjarmasonFeb 1, 2022
  20. Han-Wen NienhuysFeb 3, 2022
  21. Junio C HamanoFeb 3, 2022

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.