Re: [PATCH v3] rerere: keep a background gc from killing a rebase

"Thomas Bachem via GitGitGadget" [off-list ref] writes:

semantics of core.packedRefsTimeout, then warn and go on without
rerere: a lost recording or replay is nothing next to a rebase that
cannot continue.

I do not understand the logic at the latter half of the above
sentence.  During a rebase, any and all opportunity to reuse a
conflict resolution you made earlier is preferrable.

I would be fine if "we cannot grab the lock so let's skip without
doing 'rerere gc' at all".  But if a conflicted step in rebase that
stops and leaves conflicts in the working tree fails to record the
preimage of a conflicted path, and makes the user realize that was
what happened only after the user spends significant amount of work
to resolve the conflicts and the resolution is not added to the
rerere database, that is a huge loss.

Perhaps it is just the way the above three lines is stated and what
the code actually does may not be problematic, but I am not sure if
that is what the latter half of the above sentence is trying to say.

Thanks.