From: Han-Wen Nienhuys <hanwen@google.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: Han-Wen Nienhuys via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org, Han-Wen Nienhuys <hanwenn@gmail.com>
Subject: Re: [PATCH 3/3] t5312: prepare for reftable
Date: Thu, 3 Feb 2022 15:24:12 +0100 [thread overview]
Message-ID: <CAFQ2z_OUqMx7WiTYHGrb5A0K1d_zNVTspM+6trw+u2rqRPjYwA@mail.gmail.com> (raw)
In-Reply-To: <220201.865ypy9te7.gmgdl@evledraar.gmail.com>
On Tue, Feb 1, 2022 at 10:19 PM Ævar Arnfjörð Bjarmason
<avarab@gmail.com> wrote:
> > -test_expect_success 'pack-refs does not drop broken refs during deletion' '
> > +test_expect_success REFFILES 'pack-refs does not drop broken refs during deletion' '
> > git update-ref -d refs/heads/other &&
> > git rev-parse refs/heads/main >actual &&
> > test_cmp expect actual
>
> The setup for these is reffiles-specific, but it seems to me this is
> something we'd really like to test with reftable rather than skipping it
> entirely.
>
> I.e. the scenario described in the "we create..." comment in this file
> is something that might happen with reftable too, no?
That is tested in the 3 tests right above the ones I marked with
REFFILES ('pack-refs does not silently delete broken loose ref'). The
tests at the bottom check what happens if you have a missing SHA1 in a
packed-refs file. The reftable backend does not have a packed-refs, so
there is nothing to test.
--
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
next prev parent reply other threads:[~2022-02-03 14:24 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
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 [this message]
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_OUqMx7WiTYHGrb5A0K1d_zNVTspM+6trw+u2rqRPjYwA@mail.gmail.com \
--to=hanwen@google.com \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=hanwenn@gmail.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.