Re: [PATCH 14/18] t1404: mark tests that muck with .git directly as REFFILES.
- From
Han-Wen Nienhuys <hanwen@google.com>
- Date
- Apr 26, 2021, 18:36 UTC
- Message-ID
- <CAFQ2z_M-ahhbgnvpTXhs3nR0KJKqHtE7snqrpzi_O-M1sVCfaQ@mail.gmail.com>
- In-Reply-To
- <87mtts3z2a.fsf@evledraar.gmail.com>
On Wed, Apr 21, 2021 at 8:57 AM Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
Show 13 quoted lines
> > -test_expect_success 'broken reference blocks create' ' > > +test_expect_success REFFILES 'broken reference blocks create' ' > > prefix=refs/broken-create && > > mkdir -p .git/$prefix && > > echo "gobbledigook" >.git/$prefix/foo && > > @@ -504,7 +504,7 @@ test_expect_success 'broken reference blocks create' ' > > test_cmp expected output.err > > ' > > This doesn't seem specific to the files backend at all. I.e. if you grep > for "reference broken" in the file backends you'll find EINVAL and > REF_ISBROKEN handling, and your refs/reftable-backend.c has the same > exception handling, so presumably we can end up with broken refs.
I think it's not possible. In the files backend a broken ref is a shortread (less than 40 digits hex) or garbage following the hex (or maybe non-hex digits). This is all impossible with reftable.
I've removed EINVAL from reftable-backend.c
It's possible to have a corrupt reftable file, but that would surface as REFTABLE_FORMAT_ERROR, and is morally equivalent to an I/O error. I added a test for this; it says:
++ git update-ref refs/heads/main 69af1687b671131ed0cfa61b7fcdc907a4c21f2c fatal: update_ref failed for ref 'refs/heads/main': reftable: transaction prepare: corrupt reftable file
Show 5 quoted lines
> Anyway, much of reviewing this commit was trying to rediscover thing > that should really be in the commit message. Presumably you had to run > blame, log etc. to find the commits from Michael Haggerty and dig into > if they were relevant to reftable. Having that information in the commit > message would be *very* helpful.
I added some more explanation. I did not dig into the history or the blame, as the tests seem relevant given what I know about how the files backend works, but for that same reason irrelevant to reftable. Maybe it should be documented more explicitly how the files backend works?
-- 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