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.
Not sure if that answers all your questions, though.
