replay: support replaying 2-parent merges

git history, the new history-rewriting builtin in v2.54, dies on any merge in the rewrite path with replaying merge commits is not supported yet!. That makes it not very useful for the workflows I actually have, where almost every interesting branch contains at least one merge of a feature topic. The natural fallback, git rebase --rebase-merges, is interactive and stops to ask for re-resolution even when no re-resolution is needed.

This series lifts that limitation for the common 2-parent case. The algorithm itself is not new: Elijah Newren wrote it down in his replay design notes
[https://github.com/newren/git/blob/replay/replay-design-notes.txt] and prototyped it in a 2022 work-in-progress sketch
[https://github.com/newren/git/commit/4c45e8955ef9bf7d01fd15d9106b3bdb8ea91b45].
What is new is wiring it into the replay_revisions() API that backs both git replay and git history, plus three specific tweaks that make the trickier cases work where the WIP sketch bailed out: identical conflict-marker labels for the inner remerges of the original and the rewritten parents (so their conflict-markered trees compare equal in the regions the user did not touch), tolerating result.clean == 0 from those inner merges (their well-defined conflict-markered trees are valid inputs to the outer 3-way merge), and self-fallback for both merge parents combined with mapping the rev-range boundary commits to the onto commit.

Octopus merges and revert-of-merge are surfaced as explicit errors at the dispatch point. The split sub-command of git history continues to refuse when its target is a merge: split semantics simply do not apply there. The xdiff special mode for matching conflict-marker hunks across inner remerges, the XDL_MERGE_FAVOR_BASE variant, and the modify/delete and binary-file specials that the design notes flag as future work all remain future work.

While I was at it, git history reword had a pre-existing silent-success bug:
a positive return from replay_revisions() (which means "conflict, no updates queued") was treated as success. Obviously this should never occur, as a reword simply does not change any of the file contents, but bugs do happen. The merge-replay work is complex enough to make that class of bugs more likely, therefore I introduce error messages for those instances.

Johannes Schindelin (5):
replay: support replaying 2-parent merges
replay: short-circuit merge replay when parent and base trees are
unchanged
history.adoc: describe merge-replay support and its limits
test-tool: add a "historian" subcommand for building merge fixtures
t3454: cover merge-replay scenarios with the historian helper

 Documentation/git-history.adoc |  27 ++-
 Makefile                       |   1 +
 builtin/history.c              |  16 +-
 replay.c                       | 258 +++++++++++++++++++++++++--
 t/helper/meson.build           |   1 +
 t/helper/test-historian.c      | 189 ++++++++++++++++++++
 t/helper/test-tool.c           |   1 +
 t/helper/test-tool.h           |   1 +
 t/meson.build                  |   1 +
 t/t3451-history-reword.sh      |  21 ++-
 t/t3452-history-split.sh       |   6 +-
 t/t3454-history-merges.sh      | 308 +++++++++++++++++++++++++++++++++
 t/t3650-replay-basics.sh       |  46 ++++-
 13 files changed, 840 insertions(+), 36 deletions(-)
 create mode 100644 t/helper/test-historian.c
 create mode 100755 t/t3454-history-merges.sh

base-commit: 94f057755b7941b321fd11fec1b2e3ca5313a4e0
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-2106%2Fdscho%2Fsupport-merge-commits-in-git-history-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2106/dscho/support-merge-commits-in-git-history-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/2106

gitgitgadget