Re: reflog existence & reftable

[Junio C Hamano <gitster@pobox.com>]

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> So for that case somewhere in the guts of the reftable integration we're
> losing the distinction between asking for a log that can't exist
> v.s. one that's empty, maybe the reftable code is returning "yes I have
> logging on" or "yes I have some entries somewhere" in that case?
>
> And in "E", related to "C" isn't in unambiguous to not write it if
> there's no existing entry for the branch in question and
> core.logAllRefUpdates=false is in effect?

So, in short, we can rely on the fact that if reflog exists it will
have at least one element?  

But the original "turn logallrefupdates to false and touch the
reflog files for refs you care about" (which I recall I did for my
own use case) allowed an empty reflog in preparation to have new
entries to be appended, so in its initial state an existing reflog
can have zero element.

Is there a documented way to just "enable" a single reflog via any
Git command?  That "if a file exists, append" code dates back for
more than 15 years and I do not remember if in the target use case
I was happy enough to tell people to just "touch" the reflog file
of interest, or if I bothered to add a command support (e.g. "git
reflog create 'refs/heads/next'").

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.