Re: git-rebase-walk

From: Simon Richter <simon.richter@hogyros.de>
Date: Oct 2, 2026, 02:49 UTC
Message-ID: <f5859438-f91d-46d2-b80c-25d63937ed7c@hogyros.de>
In-Reply-To: <ar5KL4_IKXYbx3Sb@debian>

Hi,

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

Alas, this breaks down with merges, and it is slow, so I've been thinking about only listing those revisions that modify the same files as the branch being rebased, and their immediate predecessors -- the latter because the rebase should apply cleanly there.

I wonder if it would make sense to have a rebase-bisect (bisect-rebase?) 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.

    Simon