On Wed, Apr 21, 2021 at 6:55 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > If there isn't, then we could do either one of these two things. > > (1) we could add "git reflog create <ref>" and the reftable can > record the fact that "reflog exists for the ref, but no ref > movement recorded yet". Then the condition C can be checked. > > (2) we could declare that there is no way to create an empty reflog > supported across ref backends, and make the tests that rely on > the "feature" conditional on REF_FILES prerequisite. > > I have no strong preference. In the early days I found the ability > to limit which branches get logged convenient, so if reftable > backend can learn the similar trick, we would want to go route (1) > (the convenience largely came from the fact that there was no need > to add one configuration item per branch, so I do not think we would > want to bother with branch.<name>.reflog=bool configuration---that > won't be an easy-to-use substitute). On the other hand, logs are > useful, and dormant logs are not costing anything (other than holding > onto stale objects we may no longer want), so it could be that it > may not be as convenient as it used to be to be able to turn logs on > only on selected refs, in which case approach (2) is fine. Exactly, these are the two options I outlined in my original message. Both can be made to work. I slightly prefer 2 (empty reflogs don't exist, and make logging a global switch), because it is simpler to understand and document. The divergence with the files backend itself is extra complexity, though. Maybe we could deprecate the behavior and always write reflogs in the files backend too. -- 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
