From: Nico Williams Date: Thu, 01 Oct 2026 21:01:01 GMT Subject: Re: git-rebase-walk Message-ID: In-Reply-To: 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 --