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".
