Re: [PATCH/RFC 1/5] replay: support replaying 2-parent merges

[Philippe Blain <levraiphilippeblain@gmail.com>]

Hi Dscho,

> Le 4 nov. 2026 à 21:19, Johannes Schindelin via GitGitGadget <gitgitgadget@gmail.com> a écrit :
> From: Johannes Schindelin <johannes.schindelin@gmx.de>

—8<—

> ---
> builtin/history.c         |  16 ++-
> replay.c                  | 209 ++++++++++++++++++++++++++++++++++++--
> t/t3451-history-reword.sh |  21 ++--
> t/t3452-history-split.sh  |   6 +-
> t/t3650-replay-basics.sh  |  46 ++++++++-
> 5 files changed, 269 insertions(+), 29 deletions(-)
> 
> diff --git a/replay.c b/replay.c
> index f96f1f6551..3dbce095f9 100644
> --- a/replay.c
> +++ b/replay.c
> @@ -1,6 +1,7 @@
> #define USE_THE_REPOSITORY_VARIABLE
> 
—8<—

> +/*
> + * Replay a 2-parent merge commit by composing three calls into merge-ort:
> + *
> + *   R = recursive merge of pickme's two original parents (auto-remerge of
> + *       the original merge, accepting any conflicts)
> + *   N = recursive merge of the (possibly rewritten) parents
> + *   O = pickme's tree (the user's actual merge, including any manual
> + *       resolutions)
> + *
> + * The picked tree comes from a non-recursive merge using R as the base,
> + * O as side1 and N as side2. `git diff R O` is morally `git show
> + * --remerge-diff $oldmerge`, so this layers the user's original manual
> + * resolution on top of the freshly auto-merged rewritten parents (see
> + * `replay-design-notes.txt` on the `replay` branch of newren/git).

Maybe we would want to add these design notes as a technical document when this series is out of RFC ? This way we refer to our own documentation. 

—8<—

> @@ -407,17 +550,63 @@ int replay_revisions(struct rev_info *revs,
>    merge_opt.show_rename_progress = 0;
>    last_commit = onto;
>    replayed_commits = kh_init_oid_map();
> +
> +    /*
> +     * Seed the rewritten-commit map with each negative-side ("BOTTOM")
> +     * cmdline entry pointing at `onto`. This matters for merge replay:
> +     * a 2-parent merge whose first parent is the boundary (e.g. the
> +     * commit being reworded) must replay onto the rewritten boundary,
> +     * yet pick_merge_commit uses a self fallback so the second parent
> +     * (a side branch outside the rewrite range) is preserved as-is.
> +     * Pre-seeding the boundary disambiguates the two: in the map ->
> +     * rewritten, missing -> kept as-is.
> +     *
> +     * Only do this for the pick path; revert mode chains reverts
> +     * through last_commit and a pre-seeded boundary would short-circuit
> +     * that chain.
> +     */
> +    if (mode == REPLAY_MODE_PICK) {
> +        for (size_t i = 0; i < revs->cmdline.nr; i++) {
> +            struct rev_cmdline_entry *e = &revs->cmdline.rev[i];
> +            struct commit *boundary;
> +            khint_t pos;
> +            int hr;
> +
> +            if (!(e->flags & BOTTOM))
> +                continue;
> +            boundary = lookup_commit_reference_gently(revs->repo,
> +                                  &e->item->oid, 1);
> +            if (!boundary)
> +                continue;
> +            pos = kh_put_oid_map(replayed_commits,
> +                         boundary->object.oid, &hr);
> +            if (hr != 0)
> +                kh_value(replayed_commits, pos) = onto;
> +        }
> +    }
> +

I understand the intent here, we seed the replayed commit map with onto for the negative revisions, so that a merge with its first parent at the boundary gets its first parent rewritten to onto, but keeps its second parent.  But I think a further tweak is necessary. 

I tried the following: 
- amend the first parent of a merge M (manually, in detached HEAD), changing only the commit message 
- try to replay the merge. Since none of the trees have changed, and the merge-base hasn’t changed, I expect replay to succeed and keep manually resolutions from M. I ran this:

git replay --onto HEAD M^!

and because with this syntax M^2 is a negative revision, it gets mapped to onto, whereas from what I understand it should _not_ be mapped and should be left untouched by replay: the new merge should have M^2 as second parent. 

Since the second parent gets mapped to onto, the merge-base of the replayed merge is changed, so the fast past is skipped,  the new merge conflicts and the replay fails. 

Also, I think this pre-seeding should be mentionned in the commit message. 

Thank you for working on this,and Elijah for prototyping it.  It’s already is a massive time saver for me. 

Philippe.