Re: [PATCH 1/2] rebase: help user when dying with preserve-merges`

On Tue, Feb 22 2022, Philip Oakley via GitGitGadget wrote:

From: Philip Oakley <redacted>

Git will die if a "rebase --preserve-merges" is in progress.
Users cannot --quit, --abort or --continue the rebase.

This sceario can occur if the user updates their Git, or switches
to another newer version, after starting a preserve-merges rebase,
commonly via the pull setting.

One trigger is an unexpectedly difficult to resolve conflict, as
reported on the `git-users` group.
(https://groups.google.com/g/git-for-windows/c/3jMWbBlXXHM)

Tell the user the cause, i.e. the existence of the directory.
The problem must be resolved manually, `git rebase --<option>`
commands will die, or the user must downgrade. Also, note that
the deleted options are no longer shown in the documentation.

I can go and read the linked thread for the answer, but:

 		if (is_directory(buf.buf)) {
-			die("`rebase -p` is no longer supported");
+			die("`rebase --preserve-merges` (-p) is no longer supported.\n"
+			"You still have a `.git/rebase-merge/rewritten` directory, \n"
+			"indicating a `rebase preserve-merge` is still in progress.\n");
 		} else {
 			strbuf_reset(&buf);
 			strbuf_addf(&buf, "%s/interactive", merge_dir());

As much of an improvement this is, I'd be no closer to knowing what I
should do at this point.

Should I "rm -rf" that directory, downgrade my version of git if I'd
like to recover my work (as the message alludes to).

In either case I'd think that this is getting a bit past the length
where we'd have just a die() v.s. splitting it into a die()/advise()
pair. I.e. to have the advise() carry some bullet-point list about X/Y/Z
solutions, with the die() being a brief ~"we did because xyz dir is
still here".