Re: git-rebase-walk

[Nico Williams <nico@cryptonector.com>]

On Thu, Oct 01, 2026 at 10:29:41PM +0200, Alejandro Colomar wrote:
> 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.

> 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.

> 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.

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