Re: git-rebase-walk

From: Nico Williams <nico@cryptonector.com>
Date: Oct 1, 2026, 16:10 UTC
Message-ID: <ar6GExDLasWWFajm@ubby>
In-Reply-To: <ar5KL4_IKXYbx3Sb@debian>

On Thu, Oct 01, 2026 at 01:58:42PM +0200, Alejandro Colomar wrote:

Show 15 quoted lines

> 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