All of lore.kernel.org
 help / color / mirror / Atom feed
From: Han-Wen Nienhuys <hanwen@google.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"Taylor Blau" <me@ttaylorr.com>,
	"Han-Wen Nienhuys via GitGitGadget" <gitgitgadget@gmail.com>,
	git@vger.kernel.org, "Han-Wen Nienhuys" <hanwenn@gmail.com>
Subject: Re: [PATCH 2/3] t1405: mark test that checks existence as REFFILES
Date: Mon, 7 Feb 2022 10:48:47 +0100	[thread overview]
Message-ID: <CAFQ2z_Nb=wY_+B1ub0XDgZnvgCHGmFu1rjMuKgbFFir0=1PHtw@mail.gmail.com> (raw)
In-Reply-To: <xmqq4k5fr1mh.fsf@gitster.g>

On Fri, Feb 4, 2022 at 12:06 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> 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

  reply	other threads:[~2022-02-07 10:05 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-31 17:50 [PATCH 0/3] reftable related test tweaks Han-Wen Nienhuys via GitGitGadget
2022-01-31 17:50 ` [PATCH 1/3] t1405: explictly delete reflogs for reftable Han-Wen Nienhuys via GitGitGadget
2022-01-31 17:50 ` [PATCH 2/3] t1405: mark test that checks existence as REFFILES Han-Wen Nienhuys via GitGitGadget
2022-01-31 21:26   ` Taylor Blau
2022-01-31 22:15     ` Junio C Hamano
2022-02-01 20:06       ` Han-Wen Nienhuys
2022-02-01 21:03         ` Junio C Hamano
2022-02-01 21:22           ` Ævar Arnfjörð Bjarmason
2022-02-01 22:11             ` Junio C Hamano
2022-02-03 16:02               ` Han-Wen Nienhuys
2022-02-03 17:39                 ` Ævar Arnfjörð Bjarmason
2022-02-03 18:10                   ` Han-Wen Nienhuys
2022-02-03 23:06                 ` Junio C Hamano
2022-02-07  9:48                   ` Han-Wen Nienhuys [this message]
2022-02-07 16:52                     ` Han-Wen Nienhuys
2022-02-07 23:40                       ` Junio C Hamano
2022-02-08 14:58                         ` Han-Wen Nienhuys
2022-01-31 17:50 ` [PATCH 3/3] t5312: prepare for reftable Han-Wen Nienhuys via GitGitGadget
2022-02-01 21:17   ` Ævar Arnfjörð Bjarmason
2022-02-03 14:24     ` Han-Wen Nienhuys
2022-02-03 18:31       ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAFQ2z_Nb=wY_+B1ub0XDgZnvgCHGmFu1rjMuKgbFFir0=1PHtw@mail.gmail.com' \
    --to=hanwen@google.com \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.com \
    --cc=hanwenn@gmail.com \
    --cc=me@ttaylorr.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.