Re: [PATCH 2/3] t1405: mark test that checks existence as REFFILES
- From
Han-Wen Nienhuys <hanwen@google.com>
- Date
- Feb 8, 2022, 14:58 UTC
- Message-ID
- <CAFQ2z_P3MNTSDwqjfCDNU8jStCFtqXsP5vpcJsxr25B0JLxP=g@mail.gmail.com>
- In-Reply-To
- <xmqq35kugs9j.fsf@gitster.g>
On Tue, Feb 8, 2022 at 12:40 AM Junio C Hamano <gitster@pobox.com> wrote:
Show 18 quoted lines
> >> 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.
> >
> > Correction. I wish the table blocks were written in lexicographic
> > order, but they are written in order 'g', ['i',] 'o', ['i'], 'g',
> > ['i']. Since the 'g' block is last within a table, we could add a new
> > section at the end. My point that this is considerable work to think
> > through how to make this work with JGit still stands, though.
>
> As long as a fake/NULL entry in the reflog is invisible to iterators
> and does not count as part of numbered entries when reflog@{23}
> notation is used, I think it is perfectly fine to take that
> approach, instead of "separate bit". I brought it up only as a
> possible alternative (i.e. "if bit is on or any entry exists, we do
> have log for the ref") in case ignoring the fake entry is impossible.I implemented this. It was very clean and easy; I didn't yet check if JGit can handle it, but if it doesn't, it should be easy to fix.
You can drop patch 2/3 (ie. this subject line).
-- 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