From: Toon Claes Date: Tue, 07 Jul 2026 19:07:24 GMT Subject: [PATCH v7 0/3] Teach git-replay(1) to linearize merge commits Message-ID: <20260707-toon-git-replay-drop-merges-v7-0-808ab9b4afa6@iotcl.com> In-Reply-To: <20260702-toon-git-replay-drop-merges-v6-0-78a07cdd0382@iotcl.com> As an alternative to dscho's patch series to replay merges[1], add an option to git-replay(1) to linearize merges. This mimics what git-rebase(1) does with --no-rebase-merges (the default). The first two patches do some refactoring. The third patch implements the actual change. This patch was kindly provided by Dscho, which I've tweaked to be upstreamed. The --linearize option is only added to git-replay(1) and not to git-history(1) because in my opinion it doesn't make much sense to do so, but I'm happy to hear if anyone disagrees. This series might conflict with Kristoffer's series to make documentation changes[2], but should be trivial to resolve. And I don't think there's a conflict with Patrick's series on adding "drop" to git-history(1)[3]. dscho's series to replay merges[1] needs a bit of rework to fit on top of this, but I'm happy to help figuring that out. We've been discussing to either name the option --flatten or --linearize, but I've decided on "linearize" because the documentation of git-rebase(1) also mentions "linearize". [1]: [2]: [3]: <20260603-b4-pks-history-drop-v2-0-742cb5b5176d@pks.im> --- Changes in v7: - Allow --revert and --linearize to be used together. - Because quite a lot of changes have been made since the original patch, change author from Johannes to Toon for the last commit. Johannes already told me he doesn't really care about authorship when he initially shared the patch with me. - Link to v6: https://patch.msgid.link/20260702-toon-git-replay-drop-merges-v6-0-78a07cdd0382@iotcl.com Changes in v6: - Reworked the second commit that moves picking the base completely outside pick_regular_commit(), instead of adding more explanation. - Drastically extended the commit message on commit #3. - Extended docs on flattening multiple revision ranges and how it's different from git-rebase(1)'s --no-rebase-merges. - Added a bunch of tests to cover various scenarios. - Remove newline from BUG() message. - Link to v5: https://patch.msgid.link/20260626-toon-git-replay-drop-merges-v5-0-5e120738b9d0@iotcl.com Changes in v5: - Dropped the enum->bool patch and instead added a patch that better explains how pick_regular_commit() picks a base. - Order of commits is shuffled. - (BIGGEST CHANGE) When working on a refactor to undo the enum->bool patch, I extended the code comments to explain how things work. This made me realize the use of the "replayed_base" was incorrect when multiple branches are rebased with --onto. This is fixed now and a test is added for this scenario. - Link to v4: https://patch.msgid.link/20260622-toon-git-replay-drop-merges-v4-0-ff257f534319@iotcl.com Changes in v4: - Use test_grep instead of a bare grep in the range-diff test, to prepare for mm/test-grep-lint. - Link to v3: https://patch.msgid.link/20260616-toon-git-replay-drop-merges-v3-0-153e9eb99ce1@iotcl.com Changes in v3: - Add --linearize to Documentation SYNOPSIS, and mention it's incompatible with --revert. - Small language change in help message for --linearize. - Rephrase comment to include last_commit isn't modified when linearizing merges. - Remove test that was added in earlier versions, but actually is a duplicate of 'replaying merge commits is not supported yet'. - Add test to verify --revert and --linearize are incompatible. - Properly test that replaying down to root with --linearize works. - Add test for --linearize with --advance. - Add test that uses git-range-diff(1) to verify the patches created by --linearize are correct. - Link to v2: https://patch.msgid.link/20260610-toon-git-replay-drop-merges-v2-0-5714a71c6d83@iotcl.com Changes in v2: - Restructured the conditions to detect merge commits and added a line of comment why the loop continues. - Rewrote tests to use the history from the setup step and added a few test cases. - Re-added Johannes's Signed-off-by trailer. Johannes gave me the patches with this trailer, and if I understand correctly, I can keep it. Please let me know if that wrong. - Link to v1: https://patch.msgid.link/20260608-toon-git-replay-drop-merges-v1-0-e3ee71fce7b4@iotcl.com --- Toon Claes (3): replay: add helper to put entry into replayed_commits replay: resolve the replay base outside pick_regular_commit() replay: offer an option to linearize the commit topology Documentation/git-replay.adoc | 19 +++++- builtin/replay.c | 4 +- replay.c | 81 ++++++++++++++++-------- replay.h | 5 ++ t/t3650-replay-basics.sh | 140 +++++++++++++++++++++++++++++++++++++++++- 5 files changed, 221 insertions(+), 28 deletions(-) Range-diff versus v6: 1: 96637c42a9 ! 1: ce24fba6d6 replay: add helper to put entry into replayed_commits @@ Commit message replay: add helper to put entry into replayed_commits The function replay_revisions() in replay.c is rather lengthy. Extract - the logic to put a commit entry into mapped_commits into a helper - function put_mapped_commit(). + the logic to put a commit entry into a `struct mapped_commits` into a + helper function put_mapped_commit(). While at it, rename mapped_commit() to get_mapped_commit() to pair with this new function. 2: ae6c27aee6 ! 2: 6a39274c1c replay: resolve the replay base outside pick_regular_commit() @@ Commit message Move the base selection completely into the caller: replay_revisions(). This bundles all the logic of deciding on the base together. Also, this - reduces the number of parameters of pick_regular_commit(), making it's + reduces the number of parameters of pick_regular_commit(), making its interface cleaner. This refactoring doesn't bring any behavior changes. 3: 0208101e9b ! 3: 2960b9fdaf replay: offer an option to linearize the commit topology @@ ## Metadata ## -Author: Johannes Schindelin +Author: Toon Claes ## Commit message ## replay: offer an option to linearize the commit topology @@ Commit message rather than mirror git-rebase(1)'s `--rebase-merges[=]` interface, git-replay(1) uses its own `--linearize` option. - Co-authored-by: Toon Claes - Signed-off-by: Johannes Schindelin + Based-on-patches-by: Johannes Schindelin Signed-off-by: Toon Claes ## Documentation/git-replay.adoc ## @@ Documentation/git-replay.adoc: incompatible with `--contained` (which is a modif +history. Each of their refs is updated to point to its position in that +history. To linearize ranges separately, replay them in separate `git +replay` invocations. -++ -+This option is incompatible with `--revert`. + :: Range of commits to replay; see "Specifying Ranges" in @@ builtin/replay.c: int cmd_replay(int argc, OPT_END() }; -@@ builtin/replay.c: int cmd_replay(int argc, - opts.contained, "--contained"); - die_for_incompatible_opt2(!!opts.ref, "--ref", - !!opts.contained, "--contained"); -+ die_for_incompatible_opt2(!!opts.revert, "--revert", -+ opts.linearize, "--linearize"); - - /* Parse ref action mode from command line or config */ - ref_mode = get_ref_action_mode(repo, ref_action); ## replay.c ## @@ replay.c: int replay_revisions(struct rev_info *revs, @@ t/t3650-replay-basics.sh: test_expect_success 'setup' ' git switch -c conflict B && - test_commit C.conflict C.t conflict + test_commit C.conflict C.t conflict && -+ git branch -D unrelated ++ git branch -D unrelated && ++ ++ git switch -c divergent-x main && ++ test_commit X && ++ git switch -c divergent-y main && ++ test_commit Y && ++ git switch divergent-x && ++ test_merge Z divergent-y --no-ff ' test_expect_success 'setup bare' ' -@@ t/t3650-replay-basics.sh: test_expect_success '--advance and --contained cannot be used together' ' - test_grep "cannot be used together" actual - ' - -+test_expect_success '--revert and --linearize cannot be used together' ' -+ test_must_fail git replay --revert=main --linearize \ -+ topic1..topic2 2>actual && -+ test_grep "cannot be used together" actual -+' -+ - test_expect_success 'cannot advance target ... ordering would be ill-defined' ' - echo "fatal: ${SQ}--advance${SQ} cannot be used with multiple revision ranges because the ordering would be ill-defined" >expect && - test_must_fail git replay --advance=main main topic1 topic2 2>actual && @@ t/t3650-replay-basics.sh: test_expect_success '--onto with --ref rejects multiple revision ranges' ' test_grep "cannot be used with multiple revision ranges" err ' @@ t/t3650-replay-basics.sh: test_expect_success '--onto with --ref rejects multipl +' + +test_expect_success 'replay with --linearize of a divergent merge keeps both sides' ' -+ test_when_finished "git update-ref -d refs/heads/divergent-x" && -+ test_when_finished "git update-ref -d refs/heads/divergent-y" && -+ -+ # Build a real merge of two commits that diverged from a common base: -+ # -+ # X - Z (divergent-x) -+ # / / -+ # M - Y (divergent-y) -+ # -+ git switch -c divergent-x main && -+ test_commit X && -+ git switch -c divergent-y main && -+ test_commit Y && -+ git switch divergent-x && -+ test_merge Z divergent-y --no-ff && -+ + git replay --ref-action=print --linearize \ + --onto main main..divergent-x >result && + test_line_count = 1 result && @@ t/t3650-replay-basics.sh: test_expect_success '--onto with --ref rejects multipl + test_write_lines O N J I M L B A >expect && + test_cmp expect actual +' ++ ++test_expect_success 'replay --revert with --linearize reverts a range containing a merge' ' ++ git replay --ref-action=print --revert=divergent-x --linearize \ ++ main..divergent-x >result && ++ test_line_count = 1 result && ++ tip=$(cut -f 3 -d " " result) && ++ ++ git log --format=%s $tip >actual && ++ test_write_lines \ ++ "Revert \"X\"" "Revert \"Y\"" Z Y X M L B A >expect && ++ test_cmp expect actual && ++ ++ test_must_fail git cat-file -e $tip:X.t && ++ test_must_fail git cat-file -e $tip:Y.t ++' + test_done --- base-commit: ab776a62a78576513ee121424adb19597fbb7613 change-id: 20260604-toon-git-replay-drop-merges-807fa008d395