Junio C Hamano <gitster@xxxxxxxxx> writes:
> Not really. I think the comment on the RFC still stands, and I do
> not recall seeing a response to the point.
>
> One potential harm this change will bring to us is what happens to
> people who disable core.logAllRefUpdates manually after using the
> repository for a while. Their @{4} will point at the same commit no
> matter how many operations are done on the current branch after they
> do so. I wouldn't mind if "git reflog disable" command is given to
> the users prominently and core.logAllRefUpdates becomes a mere
> implementation detail nobody has to care about---in such a world, we
> could set the configuration and drop the existing reflog records at
> the same time and nobody will be hurt.
>
> If we keep the current behaviour, what are we harming instead?
> Growth of diskspace usage is an obvious one, but disks are cheaper
> compared to human brainwave cycles cost.
IIRC, the only reason why reftable implementation may want to change
the behaviour we have to avoid getting blamed for breaking is
because it cannot implement "a reflog exists, and we need to record
further ref movements by appending to it, no matter what the
configuration says" when the existing reflog is empty, because its
data structure lacks support for expressing "exists but empty".
I think the behaviour change described in the title of this message
can be limited in the scope to hurt users a lot less, and can still
satisfy the goal of helping reftable not getting blamed for
breakage, perhaps by making the behaviour for an empty but existing
reflog unspecified or implementation defined per backend.
That would allow us to avoid situation where a user can say foo@{1}
but it does not refer to the point where the branch's tip pointed
just before the most recent update to it. As an empty but existing
reflog would not give foo@{$n} for any value of $n, there is much
less risk of confusing users if we did not append new entries to it,
I would hope.
