git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Philip Oakley <philipoakley@iee.email>
Date
May 27, 2022, 12:58 UTC
Message-ID
<c7667b0b-d18c-e2e4-0a9e-45367ee8ac0e@iee.email>
In-Reply-To
<xmqq1qwgxbys.fsf@gitster.g>
On 26/05/2022 21:42, Junio C Hamano wrote:
Show 6 quoted lines
> Philip Oakley <philipoakley@iee.email> writes:
>
>>>> Make the `rebase --abort` option available to allow users to remove
>>>> traces of any preserve-merges rebase, even if they had upgraded
>>>> during a rebase.
> This patch does not make it "available", though.

Yes it does. Sorry if the terminology or explanation was poor (here we are looking at the commit message, not the user facing message?).

Currently, if the user has an in-progress rebase with preserve-merges, and now using the latest Git, they will reach the fatal die(), even if they try any of the git status suggestions of --abort, --continue, etc.  Essentially, it's a 'you shouldn't be here', lets stop right now, go straight to jail condition. We do want to permit the `rebase --abort` command option.

I can swap around the && condition so that it's clearer that we check the user isn't requesting an --abort before checking the internal directory and then dying.

Show 8 quoted lines
> 	Suggest using `--abort` to get out of the situation after a
> 	failed preserve-rebase and remove traces of ...
>
> perhaps?
>
> I do think the suggestion is worth doing if a user ever gets into
> the situation, but how likely does it happen?  A user has to start
> "rebase -p" with older Git,

.. hit a conflict, seeks help. Helper bring a personal portable Git with latest version - Oops.

Or Helper, says "Oh, your version is old, upgrade, and that'll fix it", again Oops.

> wait until Git gets updated to a future
> version of Git that includes this change, and then say "rebase -p
> --continue"?
You don't need the -p there ;-)

For this change, the "git rebase --continue" will still die() with the fatal: message. We do not have a way to continue. However..

After this change, the "git rebase --abort" will properly clear and clean the repo/status so that the user can then choose what to do.

Show 19 quoted lines
>
>>>>   	} else if (is_directory(merge_dir())) {
>>>>   		strbuf_reset(&buf);
>>>>   		strbuf_addf(&buf, "%s/rewritten", merge_dir());
>>>> -		if (is_directory(buf.buf)) {
>>>> -			die("`rebase -p` is no longer supported");
>>>> +		if (is_directory(buf.buf) && !(action == ACTION_ABORT)) {
>>>> +			die("`rebase --preserve-merges` (-p) is no longer supported.\n"
>>>> +			"Use `git rebase --abort` to terminate current rebase.\n"
>>>> +			"Or downgrade to v2.33, or earlier, to complete the rebase.\n");
>>>>   		} else {
>>>>   			strbuf_reset(&buf);
>>>>   			strbuf_addf(&buf, "%s/interactive", merge_dir());
>>> Existing issue: No _(), shouldn't we add it?
>> This `strbuf_addf` is forming a path for internal use. It just happens
>> to look like legible English ;-)
> I do not think Ævar meant "%s/interactive"; the enhanced message
> above that you inherited from the original "no longer supported"
> that was not marked for translation.
Ok.
Show 7 quoted lines
>
>>> I wonder if we should use die_message() + advise() in these cases,
>>> i.e. stick to why we died in die_message() and have the advise() make
>>> suggestions, as e4921d877ab (tracking branches: add advice to ambiguous
>>> refspec error, 2022-04-01) does.
>> Ah, maybe it's my message.. that needs translating.
> Yup.
Ok, I'd add a separate patch for that.
Show 6 quoted lines
> This whole '-p' business will go away in a few releases down, so a
> longer message give to the existing die() should be sufficient and
> there is no need for the choice between "yes, I am still weaning
> myself off of rebase -p and want to keep seeing the advice" and
> "thanks, I saw the message often enough, you no longer need to tell
> me how to get out", I would think.

I think it will take a long while for all the users, tools providers and distros to get beyond 2.33, so while each user may be weaned quickly, the generic problem is likely to continue to linger.

I hope to re-roll later next week. In general it's mainly tweaks and finesse.

Philip
Previous: Junio C HamanoNext: Junio C Hamano
Message 18 of 35 in “Die preserve ggg”
  1. 0/3 Die preserve gggPhilip Oakley via GitGitGadget, May 26, 2022
  2. 1/3 rebase.c: state preserve-merges has been removedPhilip Oakley via GitGitGadget, May 26, 2022
  3. Ævar Arnfjörð BjarmasonMay 26, 2022
  4. Philip OakleyMay 26, 2022
  5. René ScharfeMay 26, 2022
  6. Junio C HamanoMay 26, 2022
  7. René ScharfeMay 26, 2022
  8. Junio C HamanoMay 26, 2022
  9. Philip OakleyMay 27, 2022
  10. Philip OakleyMay 27, 2022
  11. Junio C HamanoMay 27, 2022
  12. Philip OakleyMay 27, 2022
  13. Ævar Arnfjörð BjarmasonMay 27, 2022
  14. 2/3 rebase: help users when dying with `preserve-merges`Philip Oakley via GitGitGadget, May 26, 2022
  15. Ævar Arnfjörð BjarmasonMay 26, 2022
  16. Philip OakleyMay 26, 2022
  17. Junio C HamanoMay 26, 2022
  18. Philip OakleyMay 27, 2022
  19. Junio C HamanoMay 27, 2022
  20. 3/3 rebase: note `preserve` merges may be a pull config optionPhilip Oakley via GitGitGadget, May 26, 2022
  21. Ævar Arnfjörð BjarmasonMay 26, 2022
  22. Philip OakleyMay 26, 2022
  23. Junio C HamanoMay 26, 2022
  24. Philip OakleyMay 27, 2022
  25. Ævar Arnfjörð BjarmasonMay 26, 2022
  26. Philip OakleyMay 26, 2022
  27. 0/4 Die preserve gggPhilip Oakley via GitGitGadget, Jun 4, 2022
  28. 3/4 rebase: note `preserve` merges may be a pull config optionPhilip Oakley via GitGitGadget, Jun 4, 2022
  29. Junio C HamanoJun 6, 2022
  30. Philip OakleyJun 11, 2022
  31. Philip OakleyJun 11, 2022
  32. Junio C HamanoJun 11, 2022
  33. 2/4 rebase: help users when dying with `preserve-merges`Philip Oakley via GitGitGadget, Jun 4, 2022
  34. 1/4 rebase.c: state preserve-merges has been removedPhilip Oakley via GitGitGadget, Jun 4, 2022
  35. 4/4 rebase: translate a die(preserve-merges) messagePhilip Oakley via GitGitGadget, Jun 4, 2022

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.