From: D. Ben Knoble Date: Fri, 03 Jul 2026 15:31:14 GMT Subject: Re: Programmatically edit the git rebase sequence? Message-ID: In-Reply-To: On Fri, Jul 3, 2026 at 9:46 AM brian m. carlson wrote: > > 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