Re: [PATCH v3 01/15] rebase: extend the options for handling of empty commits

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Phillip,

On Wed, 8 Jan 2020, Phillip Wood wrote:

> On 07/01/2020 19:15, Elijah Newren wrote:
> >
> > On Tue, Jan 7, 2020 at 6:37 AM Phillip Wood <phillip.wood123@xxxxxxxxx>
> > wrote:
> >
> > > On 24/12/2019 19:54, Elijah Newren via GitGitGadget wrote:
> > >
> > [...]
> > > > @@ -466,7 +494,10 @@ int cmd_rebase__interactive(int argc, const char
> > > > **argv, const char *prefix)
> > > >       struct option options[] = {
> > > >               OPT_NEGBIT(0, "ff", &opts.flags, N_("allow fast-forward"),
> > > >                          REBASE_FORCE),
> > > > -             OPT_BOOL(0, "keep-empty", &opts.keep_empty, N_("keep empty
> > > > commits")),
> > > > +             { OPTION_CALLBACK, 'k', "keep-empty", &options, NULL,
> > > > +                     N_("(DEPRECATED) keep empty commits"),
> > > > +                     PARSE_OPT_NOARG | PARSE_OPT_NONEG |
> > > > PARSE_OPT_HIDDEN,
> > >
> > > It is all very well deprecating --keep-empty but suddenly making
> > > '--no-keep-empty' an error goes beyond deprecation. Also I'm not sure
> > > it's worth changing these options as I think the only user is
> > > git-rebase--preserve-merges.sh
> >
> > Side track: Since git-rebase--preserve-merges.sh is deprecated and we
> > want to get rid of it, and rebase-merges exists and is a better
> > implementation of the original idea, can we just translate rebase -p
> > into rebase -r and delete git-rebase--preserve-merges.sh?  (With a few
> > wrinkles, such as telling users in the middle of an existing
> > preserve-merges-rebase that they either need to use an old version of
> > git to continue their rebase or else abort the rebase?)
>
> dscho posted some patches in November or December moving along this path, I'm
> not sure what the outcome was. It's a bit complicated by the different todo
> list formats between -p and -r but I think the end game should be to treat -p
> as -r as you suggest.

I sent some patches to switch `git svn` over to `rebase -r`, but that was
only in non-interactive mode.

In interactive mode, the todo lists indeed look too different and I think
we'll just need to wait a year or so and then we can just delete
`git-rebase--preserve-merges.sh`.

Ciao,
Dscho




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux