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 7, 2022, 09:48 UTC
Message-ID
<CAFQ2z_Nb=wY_+B1ub0XDgZnvgCHGmFu1rjMuKgbFFir0=1PHtw@mail.gmail.com>
In-Reply-To
<xmqq4k5fr1mh.fsf@gitster.g>
On Fri, Feb 4, 2022 at 12:06 AM Junio C Hamano <gitster@pobox.com> wrote:
Show 15 quoted lines
>
> Han-Wen Nienhuys <hanwen@google.com> writes:
>
> > 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.
>
> I was hoping that we already have a type of block that can be used
> to record an attribute on the ref (other than its value) and it
> would be just the matter of stealing one unused bit from such a
> record per ref to say "when answering 'does this ref have reflog?'
> say yes even when there is no log record for that refname".  Or the
> table format is extensible enough that we can add such a block
> without breaking existing clients.

That place doesn't exist, unfortunately, but even if it did, having a special reflog entry indicating existence is a better solution all around, I think. A separate per-ref bit allows for data inconsistencies: what if the bit says "there is no reflog", but we actually do have reflog entries in the 'g' section?

It also has less chances of creating complicated control flows (especially in JGit which wasn't designed for this bit from the start): the tables have to be written in lexicographic order, so you only can write this bit after you know if reflog entries were written for a certain ref.

-- 
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: Han-Wen Nienhuys
Message 14 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.