Re: git-rebase-walk

From: Alejandro Colomar <alx@kernel.org>
Date: Oct 6, 2026, 16:45 UTC
Message-ID: <asUiQhNERzwT_hWa@debian>
In-Reply-To: <asUMkBi9NG0k6fu4@ubby>

Hi Nico, Phillip,

Show 13 quoted lines

> Date: 2026-10-06 09:58:24-0500
> From: Nico Williams <nico@cryptonector.com>
>
> On Tue, Oct 06, 2026 at 03:01:29PM +0100, Phillip Wood wrote:
> > On 05/10/2026 14:37, Alejandro Colomar wrote:
> > > > Below is a shell session performing such a rebase, which hopefully shows
> > > > why I need this to be multi-shot.
> > 
> > To me it shows that we need to improve "git rebase --update-refs" so that it
> > can rebase a tree of branches automatically. Doing it manually is labor
> > intensive and error-prone (your example output shows it is easy to forget
> > when you're meant to be resolving a conflict instead aborting the rebase and
> > checking out another branch).

It's easy to forget, but that's inconsequential. What happened if I abort and try again is that I'll meet the conflict again. It's like there's a barrier, and I won't cross it until I decide to cross it.

The very worst case is when bisect-rebase presents a conflict and you forget to abort before solving it (to bring children closer before the conflict), is that I'd have to resolve the conflict twice. You face it a few times, then you learn it. But aborting too much is not a problem. That doesn't increase your work. It's just one more command, but the same amount of conflict resolutions. To summarize: aborting too much is fine (which is what happened to me); forgetting to abort will lead to having to resolve the same conflict twice (you'll eventually learn to abort early, even a bit too much, just in case).

Show 5 quoted lines

> > In the example below
> > 
> >     git rebase --update-refs --rebase-merges main B
> > 
> > will rebase A and B, but we don't have a way of including C.

--update-refs would need to present conflicts too. After each conflict, I --abort the current rebase, and do a bisect-rebase for each child that brings childs into place. Those bisect-rebase may themselves present conflicts, which must be resolved immediately (before continuing the main bisect-rebase), in case there are no grandchilds; but if there are grandchilds, that also needs to be aborted, and grandchilds need to be bisect-rebased to the child. It's a recursive problem, and I don't think we want to get into implementing a recursive rebase within rebase.

Plus, the order in which the recursion is made could be problematic (I may prefer to tackle the branches in a certain order, due to personal preferences). It's not easy.

For now, I think the safest thing is to keep it multi-shot. Once you're familiar with the interface, we may discuss whether it can be integrated into git-rebase(1).

Please, play with it for some time. Try it with trees of branches, and see how it works, and what you'd improve from it. I've used it to rebase some very old work of mine that had never found the energy to rebase. And it was amazing! Nico seems to be having the same experience. I'm not convinced I'd have the same experience.

Show 28 quoted lines

> But it's not the same problem.  This isn't about rebasing a set of
> stacked branches all at once.  This is about rebasing quickly across
> thousands of upstream commits.
> 
> Naturally one _could_ use `--update-refs` with a bisect-rebase.  The two
> features are orthogonal.
> 
> I've been using this bisect-rebase script to rebase an old branch off PG
> to the latest upstream -- that's 10,135 commits in my case(!).
> 
> > > > On the simpler case of a single branch, I'd still prefer a multi-shot
> > > > approach where --continue only advances one rebase operation, because at
> > > > the end of it I want to stop, and check git-range-diff(1) to make sure
> > > > it all makes sense.
> > 
> > Perhaps we could insert "break" commands after each branch is rebased so the
> > user can check the range-diff.
> 
> The bisect-rebase scripts do stop when a conflict is found that the user
> should resolve.  The noise from the bisection's search for that
> appropriate commit is not that interesting except as a sort of progress
> meter.  Stopping at each point in the bisection where the bisection
> would continue is not going to be that useful unless the user could
> check if the conflicts are simple and obvious enough at each point and
> skip the rest of the bisection -- is that your idea?  But if so then the
> bisection will be very painful if the user would mostly elect to
> continue it.  That could be an option -- if it works, great, and if not
> start over without that option.

I guess we could insert break points at the end only in the rebases that are known to fail (the "conflicting rebase" at the end of my script). That "could" work. I'm not convinced though.

Cheers, Alex

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