Re: [RFC] git-brebase

[Alejandro Colomar <alx@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 2434 bytes --]

Hi Nico,

> Date: 2026-10-03 15:48:46-0500
> From: Nico Williams <nico@cryptonector.com>
>
> 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.

What would --abort do?  Go back to the begining of this iteration, or to
the very first initial state of the branch?

The useful thing would be to just go back to the begining of this
iteration --that is essential for rebasing entire trees of branches, as
explained in the previous message--.

Since --abort doesn't go all the way back, I think --continue shouldn't
continue all the way forward, for consistency.

If that's desired behavior, it should go in this tool, and not as part
of git-rebase(1).  git-rebase(1) is a much simpler and much more
fundamental tool, which is used to build this more complex tool.
That's one reason I'm rather opposed to having this as part of
git-rebase(1); it would confuse about the responsibility of
git-rebase(1).  IMO, git-rebase(1) is a plumbing command, and
git-brebase would be a porcelain thingy.

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

That hints it might be just be a different command.

> 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
> -- 


Have a lovely night!
Alex

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]