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

On Tue, Jun 30, 2026 at 11:44:47AM +0200, Johannes Schindelin wrote:

On Tue, 30 Jun 2026, Patrick Steinhardt wrote:

quoted

On Fri, Jun 26, 2026 at 07:36:31AM +0200, Toon Claes wrote:

quoted

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.

Fair enough. Arguments like this are basically what I want to read in
the commit message. As said in the below snippet: I'm not against
diverging from the git-rebase(1) interface, but if we do that we should
document why we think that the current interface is bad.

[snip]

quoted

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.

Thanks!

Patrick