Re: [PATCH v4 3/3] replay: offer an option to linearize the commit topology

> On Tue, 30 Jun 2026, Patrick Steinhardt wrote:
> > On Fri, Jun 26, 2026 at 07:36:31AM +0200, Toon Claes wrote:
> > > Then there's the option of rebasing cousins left. That's something that
> > > isn't covered by Dscho's series yet. Maybe --replay-cousins?
> > > 
> > > To reiterate what the final design could look like:
> > > 
> > >  * <nothing>: replay merges preserving topology.
> > >  * "--linearize": flattens merges (only git-replay(1)).
> > >  * "--no-merges": dies when the process tries to replay a merge.
> > >  * "--replay-cousins": does what --rebase-merges=rebase-cousins does.
> > 
> > Right. And if we tried to be consistent with git-rebase(1), then this
> > could be done as:
> > 
> >   - "--rebase-merges" to replay merges preserving topology, which is the
> >     default once we support replaying them.
> > 
> >   - "--no-rebase-merges" to flatten commits.
> > 
> >   - "--rebase-merges=abort" to explicitly die when seeing merges.
> > 
> >   - "--rebase-merges=rebase-cousins"
> 
> The `git rebase` options are unlikely to be a good precedent to follow.
> Their history is full of usability warts, and in hindsight, I would really
> have loved a more steady hand in developing and maintaining a good UX. The
> fact alone that this is called `rebase` speaks volumes about how hostile
> of a user experience this command surfaces.
> 
> In any case, these options should use the much more natural term "replay"
> instead of "rebase".
> 
> But then: you said that `--no-rebase-merges` should flatten the commits?
> That's not what this option name conveys to me; It would convey to me that
> the operation would _abort_ on encountering merge commits.
> 
> In other words, I do think that the --linearize option is conceptually
> quite distinct from the different modes in which merge commits could be
> handled. As such, this option should probably not be conflated with
> the various `--replay-merges=<mode>` modes.

> > Note that I'm not arguing that we should support all of these options
> > now. I'm merely arguing that we should try to be consistent, unless
> > there is a good argument not to do that. I'm fine with the interface if
> > there indeed is a good argument, but if so we should document why we
> > think that the current interface in git-rebase(1) is not a good fit for
> > this command.