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

Re: [RFC PATCH] rebase: implement --rewind

From
Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Date
Apr 5, 2023, 15:15 UTC
Message-ID
<ZC2Qhi73YKSOJrM2@ugly>
In-Reply-To
<4fa6d2da-4885-09d9-dddb-6f19efda6398@gmx.de>
On Wed, Apr 05, 2023 at 02:07:29PM +0200, Johannes Schindelin wrote:
>This question brings me back to the initial question: What problem do 
>we try to solve here? (This is a question that try as I might, I cannot 
>see answered in the proposed commit message.)
>

and i, try as i might, don't understand what you're not understanding ...

>[...] In other words, I need a nested rebase.
>

that's just *your* private terminology. i don't apply the term "nested" here, because for me that implies the possibility to "unnest", which my patch doesn't implement. instead, it just continues past the point where the rewind was initiated. it's the difference between a loop and recursion. but outside this difference in terminology, for all i can tell, my patch implements *exactly* what you're asking for, and i don't understand why that's not obvious to you, given how well you understand the problem space yourself. please describe what you want with _a few_ words and without introducing any new terminology first, i.e., something you'd actually want to see in the feature's summary documentation. that should illuminate what keywords you find critical.

i just gave rewinding rebasing merges a shot, and it didn't work for the simple reason that --rebase-merges is not saved in the state (understandably, because that was unnecessary so far) and the combination of --rewind --rebase-merges is being rejected. i'll need to fix that.

then there is the problem that --rebase-merges only redoes merges rather than replaying them. but it seems that the simple case with unmodified parents actually does get replayed (or rather, skipped over, just incredibly slowly), so rewinding to just the last merge would work fine. other than that, i'm declaring the matter out of scope and deferring to your "replaying evil merges" sub-thread.

Previous: Johannes SchindelinNext: Ævar Arnfjörð Bjarmason
Message 5 of 11 in “rebase: implement --rewind”
  1. rebase: implement --rewindOswald Buddenhagen, Mar 23, 2023
  2. Johannes SchindelinMar 28, 2023
  3. Oswald BuddenhagenMar 28, 2023
  4. Johannes SchindelinApr 5, 2023
  5. Oswald BuddenhagenApr 5, 2023
  6. Ævar Arnfjörð BjarmasonApr 6, 2023
  7. Oswald BuddenhagenApr 6, 2023
  8. Felipe ContrerasApr 7, 2023
  9. Oswald BuddenhagenApr 7, 2023
  10. Phillip WoodApr 11, 2023
  11. Phillip WoodApr 6, 2023

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.