Re: git-rebase-walk
- From
- Nico Williams <nico@cryptonector.com>
- Date
- Oct 2, 2026, 03:19 UTC
- Message-ID
- <ar8i1Pz3Rh5F8ngx@ubby>
- In-Reply-To
- <f5859438-f91d-46d2-b80c-25d63937ed7c@hogyros.de>
On Fri, Oct 02, 2026 at 11:49:26AM +0900, Simon Richter wrote:
Show 12 quoted lines
> On 10/1/26 8:58 PM, 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?
>
> I use something similar:
>
> [alias]
> slowrebase = "!bash -c 'for i in $(git rev-list --reverse $(git
> merge-base HEAD @{u})..@{u}); do git rebase $i || break; done'"
> slowrebasemerges = "!bash -c 'for i in $(git rev-list --merges
> --reverse $(git merge-base HEAD @{u})..@{u}); do git rebase $i || break;
> done'"Nice!
> Alas, this breaks down with merges, and it is slow, so I've been thinking > [...]
A slow-rebase or bisect-rebase works best when a) you follow a rebase workflow, and b) the upstream has linear history (i.e., they also do a rebase workflow). When the upstream has merges then... improving this experience gets difficult, and the easiest thing to do is to treat the merge as a single [large] commit and not try to bisect-rebase on the merge author's branch side. But if you're looking for a slow-rebase or a bisect-rebase then chances are you're doing (a), and if the upstream doesn't have linear history then you accept the trouble.
> I wonder if it would make sense to have a rebase-bisect (bisect-rebase?)
We had a whole sub-thread on this thread about just that! :)
Show 14 quoted lines
> command that finds the first commit that the branch cannot be cleanly > rebased onto, optionally with a test command to see if there are semantic > conflicts. > > So given > > A --- B --- C --- D --- E --- F (main) > \ > a --- b --- c (feature) > > I'd like to be able to use "git bisect rebase main -x 'make check'" to > attempt rebasing onto D first, and continue on to B or E, depending on > whether the merge goes cleanly and "make check" succeeds, maybe with an > option to try F first if the resolution is trivial.
I linked to my version of this, then Alejandro re-wrote it, on this thread.
I've used mine a few times to rebase across thousands of upstream commits. It works very well, IMO.
Nico