Re: Programmatically edit the git rebase sequence?

From: D. Ben Knoble <ben.knoble@gmail.com>
Date: Jul 3, 2026, 15:31 UTC
Message-ID: <CALnO6CCaAaVTDABQT9APasnhmvL3w_C1VKo3UYhgDt29OYPmFg@mail.gmail.com>
In-Reply-To: <ake8OAIyK-ELs-fU@fruit.crustytoothpaste.net>

On Fri, Jul 3, 2026 at 9:46 AM brian m. carlson <sandals@crustytoothpaste.net> wrote:

Show 18 quoted lines

>
> On 2026-07-03 at 12:02:33, Matthias Beyer wrote:
> > Is there a way I am not aware of to do that manual step programatically?
> > Something like
> >
> >     git rebase -i master --edit-commits="$(git log master..mybranch --diff-filter=M --format="%H" -- "./subdir/*.rs")"
> >
> > would be convenient here, although I would understand if that is too
> > much clutter for the already very heavy git CLI interface :-)
>
> Yes, such a thing exists.  You want `GIT_SEQUENCE_EDITOR`, which is an
> `EDITOR`-like command that edits the rebase list in place.  So tools
> like `ed`, `ex`, `sed -i`, `perl -i`, or `ruby -i` would be useful here.
>
> So you might want something like this (untested):
>
>     GIT_SEQUENCE_EDITOR="perl -pi -e 's/^pick ($(git log master..mybranch --diff-filter=M --format="%h" -- "./subdir/*.rs" | paste -d '\''|'\'' -s -))/edit \$1/'" \
>     git rebase -i master

Yep. Although, the last time I wrote a program that used GIT_SEQUENCE_EDITOR, I had to deal with enough shell-nesting that it was more convenient to make the editor program separate:

- git-split-topic [1] sets up a sequence editor with some interpolated
arguments that also re-invokes the original
- split-topic-editor [2] pre-processes the rebase script with ed

[1]: https://github.com/benknoble/Dotfiles/blob/ca48a09f783b78e038a41c5d60ee6b163337f580/links/bin/git-split-topic#L47-L53 [2]: https://github.com/benknoble/Dotfiles/blob/master/links/bin/split-topic-editor

See the comments in [1] for some weirdness in the invocation of the sequence editor, where it gets "$@" appended to the command string (meaning the last command in a chain might need to be written specially).

And yes, I'm sure there's a few ways for things to go wrong with the way some of the shell script variables are embedded into strings for another shell to evaluate later; if I rewrote with Zsh, I could at least use the ${(q)var} forms to perhaps handle that better…

-- 
D. Ben Knoble