Junio C Hamano <gitster@xxxxxxxxx> writes:
> Han-Wen Nienhuys <hanwen@xxxxxxxxxx> writes:
>
>> I had the impression that I addressed all outstanding comments (but
>> not sure). Are you waiting for me to do something before this can go
>> into 'seen' ?
>>
>> There is a merge conflict against master, so I'll send a v4 shortly.
>
> Sorry. I seem to have looked at and commented on the precursor RFC
> of this topic, but nobody other than Ævar seems to have commented on
> the second iteration and the topic was completely under my radar,
> and I do not remember what it was about.
>
> It would be good to have an update for others to see.
>
> Thanks.
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.
As it is about the basic design of the "feature" (or misfeature), no
matter how improved the internal implementation details get, I am
skeptical how it is solved (other than "immediately when we notice
core.logAllRefUpdates is disabled, remove all the existing reflog
entries to avoid confusion, in addition to stop appending any more
reflog entries", that is).
