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. If we have to implement the "this ref has (enabled) reflog, even though there may not be any log record for it right now" bit as a fake log record, then yes, we'd have to teach the log iterator to skip such an entry and we'd have to teach the expiry logic that they are not to be expired. It certainly is a sad design than being able to express the bit in a more direct way (like file backend does, which is "presence of the reflog file gives the precense of the log, contents of the reflog file are the actual logs).
