On 23/02/2022 10:20, Ævar Arnfjörð Bjarmason wrote: > 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. In a sense, that is it. They are in a difficult place, but with at least a little information to seek further information and start making their choices. Before, they (users in difficulty) were rather uninformed. >> 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. True. That is a possibility. But we have also removed the preserve option for interaction with remotes as well. > > 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"? Why are we delaying telling the user that they would have problems there as well? It shouldn't be a game about how many ways we can trip up the user. It's a pity the problem has split into the different ways into disaster.
