Re: reflog existence & reftable

[Jeff King <peff@peff.net>]

On Fri, Apr 23, 2021 at 11:20:52AM +0200, Han-Wen Nienhuys wrote:

> 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.

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.

I'd also be perfectly happy with removing the feature on the files
backend (and perhaps replacing it with a simple globbing config value,
in case anybody really wants to log only some refs). I find it hard to
imagine that anybody would really care, but it _is_ a
backwards-incompatible change. So possibly we should do the usual
deprecation thing, or wait for a major version bump. I dunno.

-Peff