Newer, library-friendly cousin of cherry-pick.
git replay is the newer, scriptable cousin of cherry-pick/rebase. It replays a range of commits onto a target and emits update-ref lines on stdout instead of touching refs itself -- you decide when (and whether) to commit.
Think of it as a pure function: in goes (commits, newbase), out comes a transcript of ref updates. Pipe that transcript into git update-ref --stdin to apply, or inspect it first. No working tree, no detached HEAD dance.
git replay (--onto <newbase> | --advance <branch>) <revision-range>...
git replay [--contained] --onto <newbase> <oldbase>..<branch>
Writes `update-ref` commands to stdout; safe to inspect before applying.| Flag | What it does |
|---|---|
--onto <newbase> | Rebase target -- where the replayed commits should land. |
--advance <branch> | Cherry-pick style: append commits onto the tip of <branch>. |
--contained | With --onto, also move every branch fully contained in the range. |
(positional) <range> | Standard revision range, e.g. main..topic. |
(stdout) update-ref | Output is one update SP <ref> SP <new> SP <old> LF per line. |
--contained.git replay --onto main main..topicgit replay --onto main main..topic | git update-ref --stdingit replay --advance release origin/main..featuregit replay --contained --onto main old-base..tipgit replay once without piping to inspect the proposed updates.git update-ref --stdin for atomic, transactional ref updates.replay when you need scriptability; reach for rebase when you need interactivity.update-ref --stdin step is a no-op.--contained moves every contained branch -- audit the stdout before piping.Hit each option, then Check answers. Score is recorded; Next is always open.