Re: [PATCH v8 0/3] Teach git-replay(1) to linearize merge commits

[Junio C Hamano <gitster@pobox.com>]

Toon Claes <toon@iotcl.com> writes:

> 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. The original 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.
>
> 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]: <pull.2106.git.1778107405.gitgitgadget@gmail.com>
>
> ---
> Changes in v8:
> - Disallow multiple revision ranges with --linearize.
> - Disallow --contained with --linearize.
> - Link to v7: https://patch.msgid.link/20260707-toon-git-replay-drop-merges-v7-0-808ab9b4afa6@iotcl.com

The topic has been cooking in 'next' since Jul 9th, so I'll revert
the merge and queue this iteration instead, making sure I do not
accidentally merge it down to 'next' prematurely.

Thanks.