From: Nico Williams <nico@cryptonector.com>
To: Simon Richter <Simon.Richter@hogyros.de>
Cc: Alejandro Colomar <alx@kernel.org>, git@vger.kernel.org
Subject: Re: git-rebase-walk
Date: Thu, 1 Oct 2026 22:19:48 -0500 [thread overview]
Message-ID: <ar8i1Pz3Rh5F8ngx@ubby> (raw)
In-Reply-To: <f5859438-f91d-46d2-b80c-25d63937ed7c@hogyros.de>
On Fri, Oct 02, 2026 at 11:49:26AM +0900, Simon Richter wrote:
> 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! :)
> 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
--
prev parent reply other threads:[~2026-10-02 3:19 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-01 11:58 git-rebase-walk Alejandro Colomar
2026-10-01 13:22 ` git-rebase-walk Patrick Steinhardt
2026-10-01 15:51 ` git-rebase-walk Alejandro Colomar
2026-10-02 6:46 ` git-rebase-walk Patrick Steinhardt
2026-10-02 7:19 ` git-rebase-walk Alejandro Colomar
2026-10-03 19:37 ` git-rebase-walk Nico Williams
2026-10-04 10:03 ` git-rebase-walk Phillip Wood
2026-10-05 13:28 ` git-rebase-walk Alejandro Colomar
2026-10-05 13:37 ` git-rebase-walk Alejandro Colomar
2026-10-06 14:01 ` git-rebase-walk Phillip Wood
2026-10-06 14:58 ` git-rebase-walk Nico Williams
2026-10-06 16:45 ` git-rebase-walk Alejandro Colomar
2026-10-08 22:05 ` git-rebase-walk Alejandro Colomar
2026-10-08 22:07 ` git-rebase-walk Alejandro Colomar
2026-10-01 17:31 ` git-rebase-walk Junio C Hamano
2026-10-01 16:10 ` git-rebase-walk Nico Williams
2026-10-01 16:50 ` git-rebase-walk Alejandro Colomar
2026-10-01 17:40 ` git-rebase-walk Nico Williams
2026-10-01 20:29 ` git-rebase-walk Alejandro Colomar
2026-10-01 21:01 ` git-rebase-walk Nico Williams
2026-10-01 21:35 ` git-rebase-walk Nico Williams
2026-10-02 2:49 ` git-rebase-walk Simon Richter
2026-10-02 3:19 ` Nico Williams [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ar8i1Pz3Rh5F8ngx@ubby \
--to=nico@cryptonector.com \
--cc=Simon.Richter@hogyros.de \
--cc=alx@kernel.org \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.