Hi Oswald, please do reply-to-all on this list. On Tue, 28 Mar 2023, Oswald Buddenhagen wrote: > On Tue, Mar 28, 2023 at 04:53:52PM +0200, Johannes Schindelin wrote: > >I do not think that the concept in its > >current form mixes well with being in the middle of a `--rebase-merges` > >run. > > fundamentally, it shouldn't pose a problem: the already done part leads up to > a single commit, from which a complete todo with merges up to that point can > be built again, while the remainder of the pre-existing todo should be unfazed > by the fact that you're repeatedly messing with whatever branch you stopped > in. I guess the most important question is: What problem is the proposed `--rewind` option supposed to solve? If the idea is to let the user re-start the rebase (for whatever reason), throwing away the current state, then the proposed code really does not handle the `--rebase-merges` case at all. Instead, it would implicitly restart the rebase with `--no-rebase-merges`, i.e. the opposite of what the user asked for. But a more important concern is: Is this `--rewind` idea even a good one? 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.) Since I do not want to speculate about your motivation, let me explain the challenges I would like to see addressed with those rewound-or-nested rebases. I frequently find myself in _large_ rebases (we're talking about several thousand commits, with some 100-200 merge commits), where I notice in the middle that I should have resolved a previous merge conflict in a different way. Do I want to start over and redo the whole rebase? Sometimes I do, and `git rebase --abort` and the Bash history (Ctrl+R -i will get me back to the start of the interactive rebase) are my friend. No `--rewind` required. (Which makes me wonder why that same strategy is not good enough for your scenarios, too.) However, that's what I need only in a few, rare instances. What I need much, much, much more often is a way to redo only _part_ of the rebase. Like, the last 3 commits. And not from scratch, oh no! I do not want the original commits to be cherry-picked, but the ones that were already rebased. In other words, I need a nested rebase. Now, why do I keep bringing up this idea of a nested rebase, when such a nested rebase would not be able to perform a rewind as you asked? The reason is that I am still very much unconvinced that `--rewind` can do anything that `git rebase --abort` and starting over cannot do. So: no patches required, right? However, the use case that _immediately_ comes to mind when you talk about these rewinds is when a part of a rebase needs to be redone, in the middle of said rebase. And that _does_ require a nested rebase, and the `--rewind` would in most cases only throw away too much work. Ciao, Johannes P.S.: Yes, yes, I know, a nested rebase can be simulated via git worktree add --detach /tmp/throw-away && git -C /tmp/throw-away rebase -i HEAD~3 && git reset --hard $(git -C /tmp/throw-away rev-parse HEAD) && git worktree remove /tmp/throw-away but that is of course not only inconvenient, but leaves too much book-keeping and safe-guarding up to the human user, e.g. to make sure that the `git reset --hard` does not overwrite uncommitted changes/files. FWIW I simulate nested rebases in the illustrated way _a lot_.
