Hi Elijah & Rohit,
On Tue, 23 Jul 2019, Elijah Newren wrote:
> On Tue, Jul 23, 2019 at 1:01 PM Rohit Ashiwal
> <rohit.ashiwal265@xxxxxxxxx> wrote:
> > On Mon, 22 Jul 2019 11:00:40 +0100 Phillip Wood <phillip.wood123@xxxxxxxxx> wrote:
> > > [...]
> > >
> > > > @@ -489,6 +501,8 @@ int cmd_rebase__interactive(int argc, const char **argv, const char *prefix)
> > > > { OPTION_STRING, 'S', "gpg-sign", &opts.gpg_sign_opt, N_("key-id"),
> > > > N_("GPG-sign commits"),
> > > > PARSE_OPT_OPTARG, NULL, (intptr_t) "" },
> > > > + OPT_BOOL(0, "ignore-whitespace", &opts.ignore_whitespace,
> > > > + N_("ignore changes in whitespace")),
> > >
> > > As with the other patch is this actually going to be used by
> > > rebase--preserve-merges.sh?
> >
> > I added this just for the completness. Is there any discussion on
> > dropping rebase--interactive as command and may be lib'fying it while
> > deprecating rebase--preserve-merges?
>
> preserve-merges is already deprecated, see
> https://public-inbox.org/git/pull.158.git.gitgitgadget@xxxxxxxxx/ and
> the output of:
> git grep deprecated -- '*rebase*'
>
> It's also instructive to take a look at
> https://public-inbox.org/git/xmqqk1rrm8ic.fsf@xxxxxxxxxxxxxxxxxxxxxxxxx/,
> which talks about how git-rebase--preserve-merges.sh came to be; from
> reading that, it looks like the whole point of making
> rebase--preserve-merges.sh a separate script was to avoid the effort
> needed to libify it. As such, you probably just want to avoid
> breaking it or even changing it at all until it can be deleted.
> Anything that only the preserve-rebases backend uses (such as direct
> invocations of rebase--interactive, according to what Phillip said
> elsewhere in this thread), are probably better left alone as much as
> possible, with us instead documenting that preserve-merges lacks any
> new capabilities you are otherwise adding to rebase.
Indeed, libifying or even as much as enhancing it is a lot of love lost
at this stage.
> Not sure if that answers all your questions, though.
I am sure that Rohit has a lot more questions that are not answered by
this email (maybe even "What is the meaning of life?"), but one
particular (not quite asked) question that I would like to answer here
is: what does it take to actually drop `--preserve-merges`?
To answer that question, I prepared the `drop-rebase-p` branch at
https://github.com/dscho/git/commits/drop-rebase-p, essentially dropping
`git-rebase--preserve--merges.sh` and addressing the fall-out.
The biggest issue seems to be `--rebase-merges`' lack of support for
merge strategies other than the default, recursive merge one. To address
that, I implemented this patch:
https://github.com/dscho/git/commit/afa39b4fbb3ef5a53ccb9ae1f4376be87f570110
There are a couple other patches that need to broken out into their own
patch series, I just did not get to that yet.
Ciao,
Dscho
