From: Philip Oakley <philipoakley@iee.email>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: Philip Oakley via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org,
Johannes Schindelin <johannes.schindelin@gmx.de>
Subject: Re: [PATCH 1/2] rebase: help user when dying with preserve-merges`
Date: Wed, 23 Feb 2022 17:44:34 +0000 [thread overview]
Message-ID: <7cb42ab5-92c5-0a48-ffba-4f6b55ef130c@iee.email> (raw)
In-Reply-To: <220223.86r17t6fvf.gmgdl@evledraar.gmail.com>
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.
next prev parent reply other threads:[~2022-02-23 17:44 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-22 10:33 [PATCH 0/2] Update the die() preserve-merges messages to help some users Johannes Schindelin via GitGitGadget
2022-02-22 10:33 ` [PATCH 1/2] rebase: help user when dying with preserve-merges` Philip Oakley via GitGitGadget
2022-02-22 15:32 ` Ævar Arnfjörð Bjarmason
2022-02-22 16:06 ` Philip Oakley
2022-02-23 10:20 ` Ævar Arnfjörð Bjarmason
2022-02-23 17:44 ` Philip Oakley [this message]
2022-03-08 13:45 ` Ævar Arnfjörð Bjarmason
2022-02-22 10:33 ` [PATCH 2/2] rebase: `preserve` is also a pull option, tell dying users Philip Oakley via GitGitGadget
2022-02-22 15:34 ` Ævar Arnfjörð Bjarmason
2022-02-22 15:56 ` Philip Oakley
2022-02-22 17:48 ` Philip Oakley
2022-02-23 10:27 ` Ævar Arnfjörð Bjarmason
2022-03-04 14:29 ` Philip Oakley
2022-03-07 16:43 ` Johannes Schindelin
2022-03-07 23:26 ` Philip Oakley
2022-03-09 12:18 ` Johannes Schindelin
2022-02-22 18:55 ` [PATCH 0/2] Update the die() preserve-merges messages to help some users Phillip Wood
2022-02-22 20:24 ` Philip Oakley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7cb42ab5-92c5-0a48-ffba-4f6b55ef130c@iee.email \
--to=philipoakley@iee.email \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=johannes.schindelin@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).