From: Patrick Steinhardt <ps@pks.im>
Date: Mon, 29 Jun 2026 08:04:28 GMT
Subject: Re: [PATCH v4 3/3] replay: offer an option to linearize the commit topology
Message-ID: <akInDBlyWbbRFcLH@pks.im>
In-Reply-To: <87qzltyiao.fsf@emacs.iotcl.com>

On Fri, Jun 26, 2026 at 07:36:31AM +0200, Toon Claes wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> 
> > 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