Re: [PATCH 5/8] rebase: introduce the --recreate-merges option
From: Eric Sunshine <hidden>
Date: 2018-01-19 10:55:51
On Thu, Jan 18, 2018 at 10:35 AM, Johannes Schindelin [off-list ref] wrote:
quoted hunk ↗ jump to hunk
[...] 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?
quoted hunk ↗ jump to hunk
$revisions ${restrict_revision+^$restrict_revision} >"$todo" || die "$(gettext "Could not generate todo list")"diff --git a/git-rebase.sh b/git-rebase.sh@@ -262,6 +264,10 @@ do + --recreate-merges) + recreate_merges=t + test -z "$interactive_rebase" && interactive_rebase=implied + ;; --preserve-merges) preserve_merges=t test -z "$interactive_rebase" && interactive_rebase=implied