Re: [PATCH 5/8] rebase: introduce the --recreate-merges option
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Jan 29, 2018, 21:09 UTC
- Message-ID
- <nycvar.QRO.7.76.6.1801292208200.35@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz>
- In-Reply-To
- <CAPig+cQZTd77oqod8EZbXqroaaYb7oYbXUOW+jWFfRMrOMonPw@mail.gmail.com>
Hi Eric,
On Fri, 19 Jan 2018, Eric Sunshine wrote:
Show 25 quoted lines
> On Thu, Jan 18, 2018 at 10:35 AM, Johannes Schindelin
> <johannes.schindelin@gmx.de> wrote:
> > [...]
> > 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 <johannes.schindelin@gmx.de>
> > ---
> > 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