Hi Eric,

On Fri, 19 Jan 2018, Eric Sunshine wrote:

On Thu, Jan 18, 2018 at 10:35 AM, Johannes Schindelin
[off-list ref] wrote:

quoted

[...]
With this patch, the goodness of the Git garden shears comes to `git
rebase -i` itself. Passing the `--recreate-merges` option will generate
a todo list that can be understood readily, and where it is obvious
how to reorder commits. New branches can be introduced by inserting
`label` commands and calling `merge - <label> <oneline>`. And once this
mode has become stable and universally accepted, we can deprecate the
design mistake that was `--preserve-merges`.

Signed-off-by: Johannes Schindelin <redacted>
---

diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh

@@ -900,6 +900,7 @@ fi
 if test t != "$preserve_merges"
 then
        git rebase--helper --make-script ${keep_empty:+--keep-empty} \
+               ${recreate_merges:+--recreate-merges} \

If the user specifies both --preserve-merges and --recreate-merges, it
looks like --preserve-merges will take precedence.

Should git-rebase.sh have a mutual-exclusion check and error out if
both are specified?

Maybe. I welcome you to contribute such a patch once recreate-merges made
it into the code base.

In other words: this would be premature optimization. We're not at that
stage yet.

Ciao,
Dscho