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

Patrick Steinhardt [off-list ref] writes:

quoted

git-rebase(1) essentially knows about three different modes:

  - "--no-rebase-merges", which is the default and maps to your
    "--linearize".

  - "--rebase-merges", which by default doesn't rebase cousins by using
    "--ancestry-path" internally.

  - "--rebase-merges=rebase-cousins", which doesn't pass the above
    option.

So it's not a simple boolean there, which makes me wonder whether we
should mirror the same interface so that all of git-rebase(1)'s modes
can be represented, as well.

That's a valid question, although I don't know a good answer to that.

Basically you're asking for what the command line options will look
like? Allow me to think out loud.

In this series I'm adding --linearize to git-replay(1). As mentioned, I
don't think it makes sense to add it to git-history(1) as well. Without
this option, the process aborts when it encounters a merge.

Dscho sent a patch series to properly replay (2-way) merges. I think
this should become the default for both git-replay(1) and
git-history(1).

But then, do we want to have an option that brings back the current
behavior of aborting at merges? Maybe with --no-merges?

I think that would be a sensible option to have.

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"

Now, all these options are (I think) mutually exclusive, so we could
consider an option "--replay-merges=<mode>", but personally I find
"--<option>=<value>" arguments harder to use than specifying separate
options.

I think I'm avoiding your question, because the design of the command
line parameters doesn't need tot 1-on-1 correlate to the internal
datastructure. And I agree the mode isn't a boolean, but does that mean
we want to use an enum internally? Well, I don't know. And I also don't
think that matters right now. Code is easy to change, I think the
command line options should be designed with the future in mind, which I
believe we do with "--linearize".

Sorry for this long-winded rambling, but bottom line I think it's fine
to add --linearize and in the future add more options and see how the
code should evolve to support those.

Hm, I dunno. You basically reasoned that we potentially want to have all
of the same options that git-rebase(1)'s "--rebase-merges=" already
supports. So that begs the question why we need to reinvent the wheel
then and not just use the same syntax.

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