Re: reflog existence & reftable

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 21, 2021, 16:55 UTC
Message-ID: <xmqqim4fzier.fsf@gitster.g>
In-Reply-To: <87im4f3l62.fsf@evledraar.gmail.com>

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

Show 8 quoted lines

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