How do you drive a Git interactive rebase from a script without an editor?

## Two different editors An interactive rebase can open an editor twice for different purposes, and Git resolves them from different settings: - The **todo list** (the plan with `pick`/`squash`/… lines) is opened with `GIT_SEQUENCE_EDITOR`, or if unset the `sequence.editor` config, or if that is unset the ordinary editor. - **Commit messages** — for `reword`, for `squash`, for an amended commit at an `edit` stop — are opened with `GIT_EDITOR`, then `core.editor`, then the usual `VISUAL`/`EDITOR` fallbacks. Confusing the two is the classic mistake: setting only `GIT_SEQUENCE_EDITOR` and then being surprised that a `reword` still blocks on an editor. ## How the sequence editor is invoked Git writes the todo file and runs the configured command with the file's path appended as an argument, in a shell. Whatever the command leaves in the file is the plan Git executes. So it can be: - `:` or `true` — a no-op that changes nothing, meaning "run the plan exactly as generated". - `sed -i -e '...'` — a stream edit of the verbs or line order. - a script of your own that reads the file, computes a plan, and writes it back. Combining a no-op sequence editor with `--autosquash` is the most useful pattern in practice: autosquash generates the correct plan, the no-op accepts it, and the fold happens with no prompts at all. `--autostash` pairs well here too, since a script cannot answer a complaint about a dirty working tree. On macOS and BSD, `sed -i` requires an argument, so scripts that use it need to be written portably or use another tool. ## What it is good for - **Repo maintenance scripts** that fold marker commits or reword a batch of messages the same way. - **Reproducible cleanups** — a documented command that produces the same history from the same starting point, rather than "open the editor and drag these lines". - **Test harnesses** for Git tooling, where an interactive prompt would hang the run. ## What it is not good for Unattended rewriting removes the review step that the todo editor exists to provide. Whenever the plan depends on judgment — which fixes deserve a message, whether two commits are really independent — the human pass is the valuable part, and scripting it away just makes mistakes faster. Conflicts also stop a scripted rebase dead, so any automation must handle a non-zero exit and a repository left mid-rebase rather than assume success. ## Related settings and gotchas - `sequence.editor` is the persistent config equivalent, useful if you genuinely prefer a different tool for the plan than for prose. - The environment variable wins over the config, and both win over `core.editor`, so exporting it in one shell affects nothing permanently — which is exactly what you want for a one-off. - A sequence editor that exits non-zero makes Git treat the rebase as aborted. - Emptying the todo file still means "do nothing", so a buggy `sed` that deletes every line silently produces a no-op rather than a disaster — a small mercy worth knowing. - Because the rebase still rewrites commits, everything else about rewriting applies: new SHAs from the first rewritten commit onward, and a published branch that will have diverged. ## How to describe it in an interview The crisp version: the todo list is a file, the "editor" is just a command Git runs on that file, so anything that can edit a text file can drive an interactive rebase — including a no-op that accepts the generated plan. That framing shows you understand interactive rebase as a scripted replay rather than as a special interactive mode.