Merge is Not Undoable

Not sure if this is a bug or more of a feature request, but it is not possible to undo a merge.

Merging never has been, mainly on account of how it works internally. An individual binder item might have up to five (or maybe even six, I’d have to check) separate files on the disk. There is a file for the main text editor content, another for what you type into its index card, the Document Notes sidebar, style definitions in use by the document and the contents of any footnotes or comments as stored in the inspector. And that’s not even counting snapshops, along with the files used to track them and store any notes they have.

Consequently, an action that appears to you as simple as merging two different chunks of text in the outliner may in fact involve the combination and manipulation of dozens of files spread across four folders in different areas of the project format architecture—and that’s just merging two items. You can merge a hundreds if you like, involving potentialy thousands of literal files on the disk being moved around, renamed or combined.

It’s very difficult (ahem, let’s just call it impossible) to “undo” something like that. :slight_smile:

But speaking for what you can do yourself if you make a mistake, the counter-command for splitting, with Documents ▸ Split ▸ at Selection is what you want. You may still have to tease apart combined notes and synopses however, and snapshot lists will remain merged.

Moral of the story: as with other tools that operate on bulk items with no recourse, use File ▸ Back Up ▸ Back Up To… first, and set that copy aside. Edit ▸ Find ▸ Project Replace… and Documents ▸ Convert ▸ Text to Default Formatting… are two other commands to be wary of.

Thank you for this explanation.

As a thought, would it be possible on the backup tab of options, along with backup on save and backup on close, etc. for there to be “backup before running any unundoable actions”? I could post that in feature request, but perhaps there is an obvious reason why that would not be a good idea.

The main problem I can think of with that idea is that it would present an unreliable safety net, on account of there being too many unundoable actions. For example: editing the title of a card and hitting the return key. I doubt anyone one want to be bothered with a modal dialogue in a case like that, but some of these “fringe” actions like Merge are I would say a bit subjective. What about updating styles, or even worse, deleting them? While I might appreciate a dialogue that could result in 15 seconds of wait time for Project Replace, I don’t think I’d agree for Merge, at least for myself. For how I use it anyway, it’s a very fluid command that I use while very much “in the flow” of thinking about structure. So if I were bothered by a dialogue during that, I’d be inclined to shut the feature off and then I wouldn’t benefit from its more obviously beneficial cases.

Bear in mind that your daily/session backups are not necessarily all or nothing. By that I mean, if you accidentally merge a couple of items together, you don’t have to revert to the beginning of the session for the entire project. Just open the previous backup as a project alongside the open project you’re working on and drag the un-merged files over from the backup binder. When you’re done you can close and discard the copy of the backup.

Whatever the case, I like to think of File ▸ Back Up ▸ Back Up Now and the specific “Back Up To…” variant as being analogous to File ▸ Save in single-document programs. It’s a thing to I reflexively think to do before doing anything that might be destructive, and it’s a thing I do a few times during the day when I am doing a lot of work in a project.

Bind a shortcut to them, use them often, and these matters of unundoable commands will become less of an issue. That’s my experience anyway. I’ve very rarely had to use the backup system to recover from a Scrivener flaw—but my own mistakes? That’s why I am religious about backups, so I use that reinforcement to help myself keep the habit.