darcs

Issue 2581 rebase pull --reorder-patches does not update _darcs/format

Title rebase pull --reorder-patches does not update _darcs/format
Priority urgent Status resolved
Milestone Resolved in
Superseder Nosy List bfrk
Assigned To
Topics

Created on 2018-03-25.10:31:36 by bfrk, last changed 2020-08-01.10:33:23 by bfrk.

Files
File name Uploaded Type Edit Remove
accept-issue2581_-rebase-pull-__reorder_patches.dpatch bfrk, 2018-03-25.13:25:47 application/x-darcs-patch
Messages
msg20020 (view) Author: bfrk Date: 2018-03-25.10:31:35
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.
msg20027 (view) Author: bfrk Date: 2018-03-25.13:06:37
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.
msg20028 (view) Author: bfrk Date: 2018-03-25.13:25:47
I can reproduce it! The important detail I overlooked at first is that I
passed --reorder-patches. Attached is a failing test case.
Attachments
msg20038 (view) Author: gh Date: 2018-03-26.15:01:53
I pushed the failing test patch to screened and reviewed.
msg20045 (view) Author: bfrk Date: 2018-03-27.09:49:21
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.
msg20047 (view) Author: bfrk Date: 2018-03-27.10:43:11
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.
msg22352 (view) Author: bfrk Date: 2020-08-01.10:33:21
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.
History
Date User Action Args
2018-03-25 10:31:36bfrkcreate
2018-03-25 13:06:38bfrksetmessages: + msg20027
2018-03-25 13:25:48bfrksetfiles: + accept-issue2581_-rebase-pull-__reorder_patches.dpatch
messages: + msg20028
title: rebase pull does not always update _darcs/format -> rebase pull --reorder-patches does not update _darcs/format
2018-03-26 15:01:54ghsetmessages: + msg20038
2018-03-27 09:49:23bfrksetmessages: + msg20045
2018-03-27 10:43:13bfrksetmessages: + msg20047
2020-08-01 10:33:23bfrksetstatus: unknown -> resolved
messages: + msg22352