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

> On Tue, Feb 22 2022, Philip Oakley wrote:
>
>> On 22/02/2022 15:32, Ævar Arnfjörð Bjarmason wrote:
>>> 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".
>>>
>>>
>> Hi Ævar,
>>
>> Exactly. This is a slightly special, but real, case. The previous
>> message was essentially totally opaque to users. An "If I were you I
>> wouldn't start from here" response is somewhat true, so we simply tell
>> the user how they got to receive the fatal message. They can then take
>> any of the options they choose.
>>
>> Ultimately the user downgraded and managed to use "rebase --continue",
>> as advised by Git, without the response "fatal:" to complete their old
>> preserve-merges rebase.
> Right. I'm pointing out that in this proposed version of the die()
> message we stop just short of actually telling the user how to proceed.
>
> I.e. just that they have a X directory, not that they should either
> remove X and lose their work, or downgrade git, proceed, and then
> upgrade git.

>> They'll hit a similar fault in short order because when they next `pull`
>> they'll be slipped into trying the preserve-merge rebase again - that's
>> the 2/2 patch, making sure they know why.
> Well, this is "rebase". You can have been running rebases in a
> repository without ever having any interactions with remotes.

>
> And even if you had interactions with remotes you might be doing so via
> "git fetch" followed by "git rebase", and might not ever invoke "git
> pull".
>
> And even if you did a "git pull" later shouldn't the error you got here
> be sufficiently stand-alone as to tell you what to do, without needing a
> later "pull"?