Re: [PATCH v3 01/15] rebase: extend the options for handling of empty commits
From: Johannes Schindelin <hidden>
Date: 2020-01-09 21:33:06
Hi Phillip, On Wed, 8 Jan 2020, Phillip Wood wrote:
On 07/01/2020 19:15, Elijah Newren wrote:quoted
On Tue, Jan 7, 2020 at 6:37 AM Phillip Wood [off-list ref] wrote:quoted
On 24/12/2019 19:54, Elijah Newren via GitGitGadget wrote:[...]quoted
quoted
@@ -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.shSide 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