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

Thomas Bachem [off-list ref] writes:

quoted

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.

No, it's what the code does. Once the timeout is up, the conflicted
step goes on without recording the preimage, and the resolution the
user makes after that is lost, as you say.

It is a hard-to-accept regression without a good justification,
though, especially with the other efforts to tame "rerere gc" from
hogging the lock too often going on.

If you have a 100-commit "rebase" that is interrupted in the middle,
say at commit #70, at worst you should be able to hard reset and
abort it, and then restart it starting on top of the result of
applying up to commit #69 (with "rebase --onto") to finish the rest,
so failing in the middle is not like throwing the effort you made so
far away.

A gc that outlasts the timeout still stops the rebase where it does
today. With the gc giving way whenever it comes second and the
sequencer series keeping a rebase's own commits from starting one,
that should be rare. Whoever would rather wait it out can set
rerere.lockTimeout to -1, but I'd keep the default finite so a lock
left behind by a crash fails like every other lock instead of
hanging. Writing the stop state before rerere runs would let such a
rebase continue, which I can look at separately.

Stepping back a bit, what does a "conflicted step goes on without
recording the preimage" exactly look like?  "git rebase" goes on
chugging, and hits a commit that does not cleanly apply.  It leaves
a conflict and in a normal case immediately before returning the
control back to the user, its "git rerere" invocation creates a
preimage.  Even if we make "git rerere" fail to do so, it would not
be unrecoverable.  The end user has control at that point, and it is
not like the rest of rebase goes on without giving a chance to the
user to intervene and recover.

Would it make sense to LOUDLY tell the user when "git rerere" fails
to do what the user expects to do?  The output at the point of time
on the terminal would end with something like

    CONFLICT (content): Merge conflict in t/t0123-frotz.sh
    Auto-merging nitfol.c
    error: could not apply 8c7b68a8bf... nitfol: remove frotz
    Recorded preimage for 't/t0123-frotz.sh'
    Could not apply 8c7b68a8bf... # nitfol: remove frotz

if "git rerere" kicked in correctly, so if we said

    CONFLICT (content): Merge conflict in t/t0123-frotz.sh
    Auto-merging nitfol.c
    error: could not apply 8c7b68a8bf... nitfol: remove frotz
    FAILED TO RECORD PREIMAGE FOR 't/t0123-frotz.sh'
    Could not apply 8c7b68a8bf... # nitfol: remove frotz

    *** RUN "git rerere" MANUALLY BEFORE DOING ANYTHING ELSE ***
    *** IF YOU DO NOT WANT TO MAKE YOUR EFFORT IN RESOLVING ***
    *** THIS CONFLICT WASTED ***

or something similar, would that help the user?

I do not expect the "silent failure" to run "rerere" would not be
followed by automated applications of many subsequent commits that
makes it too late when the user notices what happened.  An attempt
to invoke "rerere" will always be followed by a stopped automation
and the user will have the control at that point.  So in that sense,
as long as the user is told clearly that some step that usually
happens and the user has learned to rely on did *not* happen, and
also told how to recover from the failure, it is not too bad.

Thanks.