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

Rebasing evil merges with --rebase-merges

From
IDIgor Djordjevic <igor.d.djordjevic@gmail.com>
Date
Jan 15, 2020, 21:23 UTC
Message-ID
<9355c545-08a5-ef63-f7bf-65201d50acc8@gmail.com>
In-Reply-To
<xmqqftggk2oi.fsf@gitster-ct.c.googlers.com>
On 15/01/2020 19:14, Junio C Hamano wrote:
Show 14 quoted lines
> 
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >
> > Having said that, if you ever find yourself wanting Just One Feature 
> > in `--rebase-merges` that would make it worthwhile for you to think 
> > about switching your patch-based workflow to a `rebase -ir`-based 
> > one, please let me know, and I will try my best to accommodate.
> 
> Another thing I noticed was that we may want to attempt to recreate
> an evil merge and then stop to ask confirmation.  The "rebase -ri" I
> did to sanity-check my revert for example failed to bring in the
> change made in the existing evil merge when trying to recreate the
> merge of the dl/merge-autostash topic into master..pu chain and
> silently created a fails-to-build-from-the-source tree instead.

FYI (and anyone interested), it`s something we actually brought up some two years ago, at the time of introducing `--rebase-merges` (known as `--recreate-merges` back at the time), see[1].

It ended being a lengthy and heated discussion (inside a few different topics as well, like original RFC[2] and it`s v2 update[3]), myself being guilty for dropping out eventually and not following it through, though, life taking me in another direction at the moment... but I still find this functionality to be very useful, not to say essential, even, for reliable complex merge _rebasing_ (meaning keeping "evil merge" changes, too), and not just merge _recreating_ (loosing "evil merge" changes, and worse - doing it silently, as you experienced yourself now as well).

p.s. Bringing that one up again, it can`t go without saying a huge thanks to Dscho for taking it this far in the meantime anyway <3

Regards, Buga

[1]: https://lore.kernel.org/git/bc9f82fb-fd18-ee45-36a4-921a1381b32e@gmail.com/ [2]: https://lore.kernel.org/git/87y3jtqdyg.fsf@javad.com/ [3]: https://lore.kernel.org/git/87r2oxe3o1.fsf@javad.com/

Previous: Junio C HamanoNext: Sergey Organov
Message 12 of 14 in “Problems with ra/rebase-i-more-options - should we revert it?”
  1. Phillip WoodJan 12, 2020
  2. Phillip WoodJan 12, 2020
  3. Johannes SchindelinJan 12, 2020
  4. Phillip WoodJan 17, 2020
  5. Johannes SchindelinJan 20, 2020
  6. Junio C HamanoJan 12, 2020
  7. Junio C HamanoJan 13, 2020
  8. Junio C HamanoJan 13, 2020
  9. "rebase -ri" (was Re: Problems with ra/rebase-i-more-options - should we revert it?)Junio C Hamano, Jan 13, 2020
  10. Johannes SchindelinJan 15, 2020
  11. Junio C HamanoJan 15, 2020
  12. Rebasing evil merges with --rebase-mergesIgor Djordjevic, Jan 15, 2020
  13. Sergey OrganovJan 16, 2020
  14. Junio C HamanoJan 15, 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.