Re: reflog existence & reftable

> On Wed, Apr 21, 2021 at 6:55 PM Junio C Hamano <gitster@pobox.com> 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.