On Fri, Feb 4, 2022 at 12:06 AM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Han-Wen Nienhuys <hanwen@xxxxxxxxxx> 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
