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

Re: Unreliable 'git rebase --onto'

From
EREugeniu Rosca <erosca@de.adit-jv.com>
Date
Jan 9, 2020, 10:53 UTC
Message-ID
<20200109105307.GA1349@lxhi-065.adit-jv.com>
In-Reply-To
<CABPp-BHsyMOz+hi7EYoAnAWfzms7FRfwqCoarnu8H+vyDoN6SQ@mail.gmail.com>
Hi Elijah, hi Szeder,
On Wed, Jan 08, 2020 at 02:06:22PM -0800, Elijah Newren wrote:
Show 9 quoted lines
> This looks like a known bug in rebase, in particular in the am-backend that
> rebase uses by default.  If I'm correct that it's just a context region
> issue, then this is the same bug that was recently discussed at
> https://lore.kernel.org/git/CAN_72e2h2avv-U9BVBYqXVKiC+5kHy-pjejyMSD3X22uRXE39g@mail.gmail.com/.
> The current plan is to switch the default over to the merge backend (the
> same machinery that cherry-pick uses), which doesn't suffer from the same
> shortcomings (you can see the current work being done in this area at
> https://lore.kernel.org/git/pull.679.v3.git.git.1577217299.gitgitgadget@gmail.com/
> ).
Thank you for your feedback and references, here and in [*].

Once hit by this or similar issues, I think there is high chance for people to go through the same feelings as described by Pavel in [**]:

  ---
  That's so scary that I'm going to stop using "git rebase" for now.
  ---

Some years ago I was hit by 'git merge' producing slightly different results compared to 'git rebase --onto' and 'git cherry-pick A..B' (maybe I can come up with a reproduction scenario for that too).

Since then, I usually contrast the outcomes of merging, cherry-picking and rebasing, to make sure they match, but that's painful and time-consuming.

> In the mean time, you can pass the -m flag to rebase to avoid these types
> of problems.  In fact, if you could retry with -m you may be able to
> confirm whether it's the same issue.
Indeed, neither `git rebase -m` nor `git rebase -i` exhibit the problem.

[*] https://lore.kernel.org/git/CABPp-BHsy75UGm4wTOP2_AYik_dZi-_BxtAn-hyi-ZrNRRWGuw@mail.gmail.com/T/#m1cbf80ef56c260a626146d61291d7fbabd108f1b [**] https://lore.kernel.org/git/CAN_72e2h2avv-U9BVBYqXVKiC+5kHy-pjejyMSD3X22uRXE39g@mail.gmail.com/

Thanks again.
-- 
Best Regards,
Eugeniu
Previous: Eugeniu RoscaNext: Elijah Newren
Message 19 of 22 in “Unreliable 'git rebase --onto'”
  1. Eugeniu RoscaJan 8, 2020
  2. SZEDER GáborJan 8, 2020
  3. Elijah NewrenJan 9, 2020
  4. SZEDER GáborJan 9, 2020
  5. Elijah NewrenJan 9, 2020
  6. rebase -i: stop checking out the tip of the branch to rebaseAlban Gruin, Jan 21, 2020
  7. Elijah NewrenJan 21, 2020
  8. Junio C HamanoJan 22, 2020
  9. Junio C HamanoJan 22, 2020
  10. Alban GruinJan 24, 2020
  11. rebase -i: stop checking out the tip of the branch to rebaseAlban Gruin, Jan 24, 2020
  12. Alban GruinJan 24, 2020
  13. Junio C HamanoJan 24, 2020
  14. rebase -i: stop checking out the tip of the branch to rebaseAlban Gruin, Jan 24, 2020
  15. Junio C HamanoJan 24, 2020
  16. Johannes SchindelinFeb 5, 2020
  17. Andrei RybakJan 24, 2020
  18. Eugeniu RoscaJan 9, 2020
  19. Eugeniu RoscaJan 9, 2020
  20. Elijah NewrenJan 9, 2020
  21. Eugeniu RoscaJan 10, 2020
  22. Elijah NewrenJan 10, 2020

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.