Re: [PATCH v8 0/3] Teach git-replay(1) to linearize merge commits
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jul 28, 2026, 18:26 UTC
- Message-ID
- <xmqqy0evc6n9.fsf@gitster.g>
- In-Reply-To
- <20260728-toon-git-replay-drop-merges-v8-0-ced11dffe749@iotcl.com>
Toon Claes <toon@iotcl.com> writes:
Show 25 quoted lines
> 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.