Re: git-rebase-walk

[Nico Williams <nico@cryptonector.com>]

On Thu, Oct 01, 2026 at 01:58:42PM +0200, Alejandro Colomar wrote:
> I use this little command to apply iterative rebases, which are easier
> to handle when there are large conflicts.  Are you interested in it?
> 
> 	$ cat $(which git-rebase-walk)
> 	#!/bin/bash
> 
> 	set -Eeufo pipefail;
> 
> 	git merge-base HEAD "$1" \
> 	| xargs -I{} git log --oneline {}.."$1" \
> 	| cut -f1 -d' ' \
> 	| tac \
> 	| while read -r c; do
> 		git rebase "$c";
> 	done;

You could simplify this pipeline to:

    git log --reverse --format=%H $(git merge-base HEAD "$1").."$1" |
    while read c; do git rebase "$c"; done

But:

 - you need to add conflict handling
 - this is very slow

I've tried this before, so I know it's very slow if you're rebasing
across thousands of upstream commits!

Also, you need some extra handling of conflicts.

> The source code is trivial, so I guess I don't need to explain much.
> It behaves quite nicely, IME.

It can be much too slow.  I've a better solution: bisect-rebase.sh:

https://gist.github.com/nicowilliams/ea2fa2b445c2db50d2ee6509c3526297

(The first revision of that gist is slow-rebase.sh, which is a linear
rebase like the one you posted.)

This script very efficiently finds the firts upstream commit that your
branch conflicts with, asks the user to resolve conflicts, then resumes
rebasing.

So let's say that your upstream has 1,000 commits you need to rebase
across, and 10 of those introduce conflicts (assume there's no reverts
of those for now), then this script will ask you to resolve conflicts 10
times, and each time it's clear which pair of local and upstream commits
conflict so you have the best possible context for conflict resolution.

It's like git-imerge, but better in that it's specifically geared to
rebase workflows.

I've successfully used this bisect-rebase.sh script to rebase a
postgresql fork across between 1,000 and 2,000 commits twice, each time
with significant conflicts to resolve that were much too difficult to
resolve with a plain rebase.  I.e., a plain `git rebase origin/master`
produced large conflicts where I didn't have enough context, but
bisect-rebase.sh let me resolve much smaller conflicts with a new base
that immediately introduced those conflicts, so I always had the right
context for resolving them.

PG is a perfect test case for this sort of thing because it's so large
and moves so fast.

Nico
--