From: Junio C Hamano Date: Tue, 28 Jul 2026 18:26:34 GMT Subject: Re: [PATCH v8 0/3] Teach git-replay(1) to linearize merge commits Message-ID: In-Reply-To: <20260728-toon-git-replay-drop-merges-v8-0-ced11dffe749@iotcl.com> Toon Claes 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]: > > --- > 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.