On Tue, Feb 8, 2022 at 12:40 AM Junio C Hamano <gitster@xxxxxxxxx> wrote:
> >> 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
