Re: git-rebase-walk

[Patrick Steinhardt <ps@pks.im>]

On Thu, Oct 01, 2026 at 05:51:58PM +0200, Alejandro Colomar wrote:
> Hi Patrick,
> 
> > Date: 2026-10-01 15:22:02+0200
> > From: Patrick Steinhardt <ps@pks.im>
> >
> > Hi,
> > 
> > On Thu, Oct 01, 2026 at 01:58:42PM +0200, Alejandro Colomar wrote:
> > > Hi!
> > > 
> > > I use this little command to apply iterative rebases, which are easier
> > > to handle when there are large conflicts.  Are you interested in it?
> > > 
> > > 	$ cat $(which git-rebase-walk)
> > > 	#!/bin/bash
> > > 
> > > 	set -Eeufo pipefail;
> > > 
> > > 	git merge-base HEAD "$1" \
> > > 	| xargs -I{} git log --oneline {}.."$1" \
> > > 	| cut -f1 -d' ' \
> > > 	| tac \
> > > 	| while read -r c; do
> > > 		git rebase "$c";
> > > 	done;
> > > 
> > > The source code is trivial, so I guess I don't need to explain much.
> > > It behaves quite nicely, IME.
> > > 
> > > You may of course want to adapt it a little bit for merging in git(1).
> > > I could help improve it a little bit.
> > 
> > this reminds me a bit of git-imerge [1]. What this tool does is to
> > basically perform a merge between two branches incrementally using a
> > matrix. The tool tries to address exactly your use case, which is to
> > "present the user with one pairwise conflict at a time for resolution".
> 
> Yup, from the description, it seems to do the same thing.  Thanks!
> I've also seen at least one other tool that does the same thing.
> 
> > Maybe that tool is interesting to you.
> 
> Not much, because I prefer a 9-line shell script that's robust as a rock
> vs. a 4k+ LoC python script for the same functionality.  :-)
> 
> > But it's certainly fallen a bit
> > out of date, as it hasn't received any updates for more than 6 years by
> > now. Chances are it stll works alright though.
> 
> My script I use it in shadow-utils and in the Linux man-pages project,
> and is in use today.  I was wondering if there was interest in
> integrating it to git(1). 

I guess the answer is "maybe". The fact that multiple folks have solved
similar issues over the course of many years is an indicator that the
funcitonality may be more generally useful. But it probably shouldn't be
a separate script, so if we wanted to integrate it I'd think the best
way forward would be to integrate it into git-rebase(1) directly.

That's of course more involved though, so I understand in case you're
not interested in doing that.

> If not, I will likely provide it in the man-pages repository as a help
> tool (which might end up packed by distros as part of manpages-utils).
> Is that okay to you?  (I ask mainly because it's using the git-
> namespace for commands, so you should at lease be aware of it.)

I mean overall this is our primary way of extension, by picking up
utilities that have the "git-" prefix. So arguably you don't have to ask
us for permission to do that.

Whether it makes sense to distribute such a tool as part of
manpages-utils is a different question, and one where I myself am of a
split mind. But that feels more like a question for distributors rather
than for us in the Git project.

Thanks!

Patrick