Re: git-rebase-walk

From: Nico Williams <nico@cryptonector.com>
Date: Oct 1, 2026, 21:01 UTC
Message-ID: <ar7KDbV2ra7Rtzl6@ubby>
In-Reply-To: <ar69ZZ4r9ZxISIHz@debian>

On Thu, Oct 01, 2026 at 10:29:41PM +0200, Alejandro Colomar wrote:

Show 6 quoted lines

> Here's the implementation:
> 
> [...]
> 
> It seems to work fine, and the source file uses 52 lines (including
> blank lines).  The behavior seems intuitive, and not too verbose.

Yes, exactly.

Show 5 quoted lines

> Now, compared to your script, the source length is similar (most of the
> difference is printf calls).  I use more pipes, while you use shell
> features like arrays (I have a very hard time reading shell code that
> does heavy use of shell features).  Other than that, they look
> fundamentally similar (except for the paragraph below).  :)

Indeed. My script minus unnecessary vertical whitespace and printfs is very similar in size.

Show 5 quoted lines

> One thing I'm surprised, though, is that you take two parameters instead
> of just the target branch.  I very much prefer my script in this sense,
> which is like git-rebase(1), which rebases the active branch on top of
> the target commit.  It's up to the caller to make sure that the active
> branch is the right one.

Oh, I know... I... was being paternalistic there. It's completely unnecessary, I agree. I'll remove it.

Show 12 quoted lines

> > > I'll certainly try your script; thanks!
> > > 
> > > Out of curiosity, did you offer this script to git(1)?
> > 
> > No, though I think I've mentioned it here before.  I'd be happy to
> > submit a patch, but I'd first have to get employer approval for it
> > (which is not a problem -- it will only take time).
> 
> Please!  :)
> 
> Or I could send mine; I don't need to do any paperwork.
> Actually, due to the difference in parameters, I prefer to send mine.

You're there already, so go for it. You can credit Vitor Dukhovni and me for this idea (he wrote slow-rebase.sh, and he and I rewrote it together into bisect-rebase.sh when I just didn't have the patience to babysit a slow rebase of my PG work), though.. it's fairly obvious, so much so that there's also the three alternatives mentioned by @pabs3 in a comment on my gist any or all of which you could credit as well, and probably more if you look hard enough:

    https://github.com/CTSRD-CHERI/git-mergify-rebase
    https://github.com/mhagger/git-imerge/
    https://github.com/brooksdavis/mergify/

I agree with you: smaller and simpler is better, which is one reason I prefer bisect-rebase.sh over git-imerge. But I confess I've not looked a those three alternatives in much detail because, frankly, bisect-rebase.sh is so simple and easy to use, and since I [co-]wrote it, I know it well, so for me it's the best choice. Since it seems to be a best choice for someone other than me, it might actually be a good choice for others.

Nico