replay: offer an option to linearize the commit topology
One of the stated goals of git-replay(1) is to allow implementing the git-rebase(1) functionality on the server side. The default mode of git-rebase(1) is to act as if `--no-rebase-merges` was given. This mode drops merge commits instead of replaying them, and linearizes the history into a sequence of regular (single-parent) commits. Add option `--linearize` to git-replay(1) to do the same. Each replayed commit is stacked on top of the previously replayed one. When a merge is encountered, the commits reachable from all of its sides are replayed into the single line and the merge itself is dropped. If a ref was pointing to a merge commit, that ref is updated to the merge's last replayed ancestor. git-replay(1) accepts multiple revision ranges, for example: $ git replay --onto main topic1 topic2 Without `--linearize` this replays 'topic1' and 'topic2' onto 'main' independently and updates both refs. With `--linearize` the whole set is flattened into one line: the ranges are stacked on top of each other rather than replayed side by side, so both refs end up pointing at different points along that single history. Replaying all revision ranges into one single linear history is intentional and it's the only way to ensure predictable results. A user who wants to linearize ranges independently is advised to use separate git-replay(1) invocations. Linearizing is a distinct operation, and flattening merge commits is just one aspect of that. Recreating merges would be a separate mode, so rather than mirror git-rebase(1)'s `--rebase-merges[=<mode>]` interface, git-replay(1) uses its own `--linearize` option. Based-on-patches-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Toon Claes <toon@iotcl.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Toon Claes committed
Jul 7, 2026 at 21:07 UTC
5bf15ad0c0fdeac41510818d214429d3888a7397
5 files changed
+199
-23
Documentation/git-replay.adoc
+18
-1
@@ -10,7 +10,7 @@ SYNOPSIS
10
--------
11
[verse]
12
(EXPERIMENTAL!) 'git replay' ([--contained] --onto=<newbase> | --advance=<branch> | --revert=<branch>)
13
- [--ref=<ref>] [--ref-action=<mode>] <revision-range>
13
+ [--ref=<ref>] [--ref-action=<mode>] [--linearize] <revision-range>
14
15
DESCRIPTION
16
-----------
@@ -88,6 +88,23 @@ incompatible with `--contained` (which is a modifier for `--onto` only).
88
+
89
The default mode can be configured via the `replay.refAction` configuration variable.
90
91
+--linearize::
92
+ In this mode, each replayed commit is stacked on top of the
93
+ previously replayed one, so all replayed commits are flattened into
94
+ a single linear history.
95
++
96
+When a merge commit is encountered, the behavior of git-rebase(1)'s
97
+option `--no-rebase-merges` is imitated. All commits in the range
98
+reachable from the merge commit are replayed into a linear history, and
99
+the merge commit itself is dropped. A ref that pointed to a merge commit
100
+is updated to the merge's last replayed ancestor.
101
++
102
+This flattens the `<revision-range>` as a whole. When multiple revision
103
+ranges are given they are stacked on top of each other into one linear
104
+history. Each of their refs is updated to point to its position in that
105
+history. To linearize ranges separately, replay them in separate `git
106
+replay` invocations.
107
+
108
<revision-range>::
109
Range of commits to replay; see "Specifying Ranges" in
110
linkgit:git-rev-parse[1]. In `--advance=<branch>` or
builtin/replay.c
+3
-1
@@ -85,7 +85,7 @@ int cmd_replay(int argc,
85
const char *const replay_usage[] = {
86
N_("(EXPERIMENTAL!) git replay "
87
"([--contained] --onto=<newbase> | --advance=<branch> | --revert=<branch>)\n"
88
- "[--ref=<ref>] [--ref-action=<mode>] <revision-range>"),
88
+ "[--ref=<ref>] [--ref-action=<mode>] [--linearize] <revision-range>"),
89
NULL
90
};
91
struct option replay_options[] = {
@@ -111,6 +111,8 @@ int cmd_replay(int argc,
111
N_("mode"),
112
N_("control ref update behavior (update|print)"),
113
PARSE_OPT_NONEG),
114
+ OPT_BOOL(0, "linearize", &opts.linearize,
115
+ N_("drop merge commits, replaying only non-merge commits")),
116
OPT_END()
117
};
118
replay.c
+34
-20
@@ -433,26 +433,40 @@ int replay_revisions(struct rev_info *revs,
433
while ((commit = get_revision(revs))) {
434
const struct name_decoration *decoration;
435
436
- /*
437
- * Decide where to replay this commit on.
438
- * If the parent commit was replayed already, the replayed result
439
- * can be found in `replayed_commits`. Otherwise fall back to `onto`.
440
- * When reverting, commits are replayed in reverse order and thus
441
- * its parent isn't replayed yet. Therefore revert commits are
442
- * always replayed onto `last_commit`.
443
- */
444
- struct commit *parent = commit->parents ? commit->parents->item : NULL;
445
- struct commit *base = get_mapped_commit(replayed_commits, parent, onto);
446
-
447
- if (mode == REPLAY_MODE_REVERT)
448
- base = last_commit;
449
-
450
- if (commit->parents && commit->parents->next)
451
- die(_("replaying merge commits is not supported yet!"));
452
-
453
- last_commit = pick_regular_commit(revs->repo, commit, base,
454
- &merge_opt, &result,
455
- mode, opts->empty);
436
+ if (commit->parents && commit->parents->next) {
437
+ if (!opts->linearize)
438
+ die(_("replaying merge commits is not supported yet!"));
439
+ /*
440
+ * Drop the merge commit: do not pick it, leave
441
+ * `last_commit` unchanged, and fall through to the
442
+ * rest of the loop. As a result:
443
+ * - refs pointing to the merge commit will be updated
444
+ * to `last_commit`.
445
+ * - the next replayed commit uses `last_commit` as its
446
+ * `base`.
447
+ */
448
+ } else {
449
+ /*
450
+ * Decide where to replay this commit onto.
451
+ * If the parent commit was replayed already, the replayed result
452
+ * can be found in `replayed_commits`. Otherwise fall back to `onto`.
453
+ * When reverting, commits are replayed in reverse order and thus
454
+ * its parent isn't replayed yet. Therefore revert commits are
455
+ * always replayed onto `last_commit`.
456
+ * Also when opts->linearize is true, set the base to
457
+ * `last_commit` to create a single linear history.
458
+ */
459
+ struct commit *parent = commit->parents ? commit->parents->item : NULL;
460
+ struct commit *base = get_mapped_commit(replayed_commits, parent, onto);
461
+
462
+ if (opts->linearize || mode == REPLAY_MODE_REVERT)
463
+ base = last_commit;
464
+
465
+ last_commit = pick_regular_commit(revs->repo, commit, base,
466
+ &merge_opt, &result,
467
+ mode, opts->empty);
468
+ }
469
+
470
if (!last_commit)
471
break;
472
replay.h
+5
@@ -62,6 +62,11 @@ struct replay_revisions_options {
62
* Defaults to REPLAY_EMPTY_COMMIT_DROP.
63
*/
64
enum replay_empty_commit_action empty;
65
+
66
+ /*
67
+ * Whether to linearize the commits (i.e. drop merge commits).
68
+ */
69
+ int linearize;
70
};
71
72
/* This struct is used as an out-parameter by `replay_revisions()`. */
t/t3650-replay-basics.sh
+139
-1
@@ -52,8 +52,19 @@ test_expect_success 'setup' '
52
test_merge P O --no-ff &&
53
git switch main &&
54
55
+ git switch --orphan unrelated &&
56
+ test_commit unrelated-root &&
57
+
58
git switch -c conflict B &&
56
- test_commit C.conflict C.t conflict
59
+ test_commit C.conflict C.t conflict &&
60
+ git branch -D unrelated &&
61
+
62
+ git switch -c divergent-x main &&
63
+ test_commit X &&
64
+ git switch -c divergent-y main &&
65
+ test_commit Y &&
66
+ git switch divergent-x &&
67
+ test_merge Z divergent-y --no-ff
68
'
69
70
test_expect_success 'setup bare' '
@@ -565,4 +576,131 @@ test_expect_success '--onto with --ref rejects multiple revision ranges' '
576
test_grep "cannot be used with multiple revision ranges" err
577
'
578
579
+test_expect_success 'replay to rebase merge commit with --linearize' '
580
+ git replay --ref-action=print --linearize \
581
+ --onto main I..topic-with-merge >result &&
582
+
583
+ test_line_count = 1 result &&
584
+
585
+ git log --format=%s $(cut -f 3 -d " " result) >actual &&
586
+ test_write_lines O N J M L B A >expect &&
587
+ test_cmp expect actual
588
+'
589
+
590
+test_expect_success 'replay to rebase merge commit with --linearize down to the root commit' '
591
+ git replay --ref-action=print --linearize \
592
+ --onto unrelated-root topic-with-merge >result &&
593
+
594
+ test_line_count = 1 result &&
595
+
596
+ git log --format=%s $(cut -f 3 -d " " result) >actual &&
597
+ test_write_lines O N J I B A unrelated-root >expect &&
598
+ test_cmp expect actual
599
+'
600
+
601
+test_expect_success 'replay to cherry-pick merge commit with --linearize' '
602
+ git replay --ref-action=print --linearize \
603
+ --advance main I..topic-with-merge >result &&
604
+
605
+ test_line_count = 1 result &&
606
+
607
+ git log --format=%s $(cut -f 3 -d " " result) >actual &&
608
+ test_write_lines O N J M L B A >expect &&
609
+ test_cmp expect actual &&
610
+
611
+ printf "update refs/heads/main " >expect &&
612
+ printf "%s " $(cut -f 3 -d " " result) >>expect &&
613
+ git rev-parse main >>expect &&
614
+ test_cmp expect result
615
+'
616
+
617
+test_expect_success 'replay --linearize produces the same patches' '
618
+ git replay --ref-action=print --linearize \
619
+ --onto main I..topic-with-merge >result &&
620
+
621
+ test_line_count = 1 result &&
622
+ tip=$(cut -f 3 -d " " result) &&
623
+
624
+ # range-diff does not care about the dropped merge,
625
+ # so the original commits (I..topic-with-merge)
626
+ # and the replayed chain (main..tip) must produce identical patches.
627
+ git range-diff I..topic-with-merge main..$tip >out &&
628
+ test_file_not_empty out &&
629
+ test_grep ! -v "=" out &&
630
+
631
+ git log --oneline main..$tip >out &&
632
+ test_line_count = 3 out
633
+'
634
+
635
+test_expect_success 'replay with --linearize rebase multiple divergent branches into a single line' '
636
+ git replay --ref-action=print --linearize \
637
+ --onto main ^B topic2 topic3 topic4 >result &&
638
+
639
+ test_line_count = 3 result &&
640
+ cut -f 3 -d " " result >new-branch-tips &&
641
+
642
+ >expect &&
643
+ for i in 2 3 4
644
+ do
645
+ printf "update refs/heads/topic$i " >>expect &&
646
+ printf "%s " $(grep topic$i result | cut -f 3 -d " ") >>expect &&
647
+ git rev-parse topic$i >>expect || return 1
648
+ done &&
649
+
650
+ test_cmp expect result &&
651
+
652
+ test_write_lines E D C M L B A >expect2 &&
653
+ test_write_lines H G F E D C M L B A >expect3 &&
654
+ test_write_lines J I H G F E D C M L B A >expect4 &&
655
+
656
+ for i in 2 3 4
657
+ do
658
+ git log --format=%s $(grep topic$i result | cut -f 3 -d " ") >actual &&
659
+ test_cmp expect$i actual || return 1
660
+ done
661
+'
662
+
663
+test_expect_success 'replay with --linearize of a divergent merge keeps both sides' '
664
+ git replay --ref-action=print --linearize \
665
+ --onto main main..divergent-x >result &&
666
+ test_line_count = 1 result &&
667
+ tip=$(cut -f 3 -d " " result) &&
668
+
669
+ # The merge Z is dropped, but both X and Y are linearized onto main;
670
+ # neither side is lost.
671
+ git log --format=%s main..$tip >actual &&
672
+ test_write_lines Y X >expect &&
673
+ test_cmp expect actual
674
+'
675
+
676
+test_expect_success '--linearize with --contained updates contained refs' '
677
+ git replay --ref-action=print --linearize --contained \
678
+ --onto main ^B topic-with-merge >result &&
679
+
680
+ test_line_count = 2 result &&
681
+
682
+ git log --format=%s $(head -n 1 result | cut -f 3 -d " ") >actual &&
683
+ test_write_lines J I M L B A >expect &&
684
+ test_cmp expect actual &&
685
+
686
+ git log --format=%s $(tail -n 1 result | cut -f 3 -d " ") >actual &&
687
+ test_write_lines O N J I M L B A >expect &&
688
+ test_cmp expect actual
689
+'
690
+
691
+test_expect_success 'replay --revert with --linearize reverts a range containing a merge' '
692
+ git replay --ref-action=print --revert=divergent-x --linearize \
693
+ main..divergent-x >result &&
694
+ test_line_count = 1 result &&
695
+ tip=$(cut -f 3 -d " " result) &&
696
+
697
+ git log --format=%s $tip >actual &&
698
+ test_write_lines \
699
+ "Revert \"X\"" "Revert \"Y\"" Z Y X M L B A >expect &&
700
+ test_cmp expect actual &&
701
+
702
+ test_must_fail git cat-file -e $tip:X.t &&
703
+ test_must_fail git cat-file -e $tip:Y.t
704
+'
705
+
706
test_done