In darcs, what if I want to re-order to the top (or just throw away) a patch which other patches depend on (i.e., change the same file)?
In git, I'd simply do a git rebase -i <UNTOUCHED-REVISION> and reorder or throw away some changes; then git would in a dumb fashion try to apply the old changes to the new variant of the tree one by one, and ask me to resolve the arising conflicts.
In darcs, I see no way to force it to ignore the dependencies between patches. If I obliterate or suspend (or unrecord) a patch which other patches depend on, darcs refuses to do it. (Because it wants to behave in a clever manner.)
I had the following plan to do this:
Here are some notes on how all this has proceeded.
1. suspend the dependent patches
If among the patches dependent on the patch you want to re-order there is a single "minimal" one (according to the graph of dependencies), then you simply give the command to suspend it (and after that there will be no "active" patches which would depend on the re-ordered patch):
(and confirm the suspension of all other dependent patches).
Of course, if there are several minimal dependent patches, you have to suspend each (each's subgraph will be asked for suspension).
2. save and revert the unwanted changes
Preparation
First, I look at the changes I'm going to work with:
(The change was logically simple, but
diffshowed it in a complicated way, so, here, I launched Emacs's ediff via a special function I had written for this purpose.)I saw that the change included some cleanup and the addition of a new feature. So, the plan is now to split it: unrecord the patch, and record two patches instead.
Now, I can view and (perhaps, work) with the changes with ediff, too.
First, I record the cleanup patch (selecting and editing only the relevant hunks). Then, the added action:
Saving as a patch (a variant)
One could use
darcs obliterate -oor-Oto save the obliterated change, and then restore it withdarcs apply(according to that advice).But I proceeded differently:
Saving as a branch (a variant)
Cloning didn't work for a repo with suspended patches:
So, let's make a copy (and check whether we would be allowed to pull from it):
Ok, good, so we will pull from that repo later.
Revert the changes
Throw away the unwanted (or re-ordered) patch:
3. Unsuspend the patches that should come before it
It's a good idea to make a backup copy of the repo at this point, because you might screw something up during the unsuspending and resolving conflicts.
Unsuspend the patches that should come before it. (Unfortunately, external merge tool is not supported in
unsuspend.) It's better to unsuspend them one by one as you'll have to resolve the conflicts caused by each one and amend the patch:4. Apply the saved patch
5. Unsuspend all remaining patches.
(Again, it's better to do this one by one.)
(For some reason, on the first attempt, I lost a hunk in the last unsuspended patch. But I repeated everything in a copy of the backup copy, and there I reached the wished final state.)