I did darcs rebase pull and answered 'a' twice (for the patches to pull
and the patches to suspend) then said darcs rebase log and it says 'no
rebase going on'. Indeed there is no 'rebase-in-progress' in
_darcs/format. After an "echo rebase-in-progress >> _darcs/format"
everything is okay.
This is nasty. Users will think all the suspended changes have been
nuked and despair.
It could be that there is a race condition, because I am having
difficulties to reproduce the problem. But I know that it happened to me
before. It seems to be correlated to the number of patches to pull or
the number of patches to suspend.
I have made some progress understanding this bug. Apparently, rebase
pull --reorder produces two rebase patches in the inventory, of which
the second one is empty. When D.R.rebase.checkSuspendedStatus uses
takeAnyRebase to look at "the" rebase patch it gets this last bogus one,
finds it is empty and thus thinks the rebase is finished.
The next step is to find out how it comes we have two rebase patches.
Fixed it, see Patch1671. I think what broke it was:
10: patch 26123acb8287f6ef6eceb8c72b52b34cdd1a0d5c
Author: Ben Franksen <ben.franksen@online.de>
Date: Mon Oct 2 13:33:44 CEST 2017
* refactor handling of --reorder-patches in tentativelyMergePatches_
which is what I thought all along. Still, I couldn't see the obvious
until I convinced myself the bug /must/ be in there.
Resolved by
patch 9f28a819ffaaa5446ce4e5683878b880eabf4825
Author: Ben Franksen <ben.franksen@online.de>
Date: Tue Mar 27 12:29:50 CEST 2018
* resolve issue2581: avoid adding rebase patch twice
In tentativelyMergePatches_, when we handle the --reorder-patches
case, we
filter out any local rebase patch before removing our unmerged
patches, so
when we add the merged patches back we also have to filter out the
rebase
patch.