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 can reproduce it! The important detail I overlooked at first is that I
passed --reorder-patches. Attached is a failing test case.

Attachments

• accept-issue2581_-rebase-pull-__reorder_patches.dpatch

I pushed the failing test patch to screened and reviewed.

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.