Re: [GSoC][PATCH v2 1/1] rebase -i: add --ignore-whitespace flag
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Jul 24, 2019, 11:14 UTC
- Message-ID
- <nycvar.QRO.7.76.6.1907241308500.21907@tvgsbejvaqbjf.bet>
- In-Reply-To
- <CABPp-BE1=FB3LXAZP+i0Mj2OZQ7kTx2s3S+fZR9Y7EAg8KhqRg@mail.gmail.com>
Hi Elijah & Rohit,
On Tue, 23 Jul 2019, Elijah Newren wrote:
Show 36 quoted lines
> On Tue, Jul 23, 2019 at 1:01 PM Rohit Ashiwal
> <rohit.ashiwal265@gmail.com> wrote:
> > On Mon, 22 Jul 2019 11:00:40 +0100 Phillip Wood <phillip.wood123@gmail.com> 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@gmail.com/ and
> the output of:
> git grep deprecated -- '*rebase*'
>
> It's also instructive to take a look at
> https://public-inbox.org/git/xmqqk1rrm8ic.fsf@gitster-ct.c.googlers.com/,
> 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