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

[Philippe Blain <levraiphilippeblain@gmail.com>]

> Le 5 nov. 2026 à 07:38, Philippe Blain <levraiphilippeblain@gmail.com> a écrit :
> Hi Dscho,
> 
>> Le 4 nov. 2026 à 21:19, Johannes Schindelin via GitGitGadget <gitgitgadget@gmail.com> a écrit :
>> From: Johannes Schindelin <johannes.schindelin@gmx.de>
> 
>> @@ -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.

After reading Elijah’s tip commit message on his replay-upstream branch, which does the same pre-seeding as is done in yours, I understand that I can achieve what I want via 

git replay --onto HEAD ^M^1 M --ancestry-path

which covers this use case, and also covers rewriting only the second parent too. I think it might be useful to mention the fact that negative revisions are mapped to onto in the documentation of 'git replay' ? At least, I think it might not be obvious to some users that to replay a merge with only one of its parent changed, you can’t use M^! and must use --ancestry-path. 

> 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.

Reading Elijah’s branch, this pre-seeding logic might even deserves its own commit ? I like how Elijah explains how we extend the ruleset on how to choose a replayed commit’s parent(s). 

Cheers,

Philippe.