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

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

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

> From: Philip Oakley <philipoakley@iee.email>
>
> 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".