Thread (3 messages) flat view 3 messages, 3 authors, 2021-11-11

Re: [PATCH v3 0/7] Gets rid of "if reflog exists, append to it regardless of config settings"

From: Junio C Hamano <hidden>
Date: 2021-10-07 17:38:37

Junio C Hamano [off-list ref] 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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help