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

> 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?

> 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.

> 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.