Re: [RFC] git-brebase

From: Nico Williams <nico@cryptonector.com>
Date: Oct 3, 2026, 20:48 UTC
Message-ID: <asFqLv3hMEE7yEOC@ubby>
In-Reply-To: <asFoDZKscLKqaIf+@ubby>

On Sat, Oct 03, 2026 at 03:39:41PM -0500, Nico Williams wrote:

> that it deserves a name.  But also, `git-rebase(1)` should always have
> been this useful, so that argues for this to be either... a new option
> like `--onto-first-conflict`, or even a new default behavior.

I.e., maybe if I run `git rebase $upstream/$branch` and there's conflicts then it should do this bisection to drop me at the first upstream commit to introduce conflicts, stop, inform me of this, inform me that after I finish resolving conflicts I need to run `git rebase --continue` until that's done, that I should then `git rebase $upstream/$branch` again.

Additionally when `git rebase --continue` finishes successfully, if we're not at `$upstream/$branch` then `--continue` should run `git rebase $upstream/$branch` directly. This means recording the target committish along with other git rebase state during the rebase. This would feel very natural to me.

If we take this approach then we'd need an option not to enable this behavior but to disable it, something like `--direct`.

The more I think about it, the more I want this approach to be the default for `git rebase`. But maybe there's a good reason not to? Maybe first ship the option, then later make it the default?

Nico