Re: reflog existence & reftable

> > >  (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.
>
> Yeah, I like (2) as well. This "write a reflog if it always exists"
> behavior has always seemed hacky, and like a leftover from early days
> when we didn't just turn reflogs on by default. Given that it was
> documented as "touch the file", I don't see any need to pretend that it
> makes any sense at all in a reftables world.