Re: [PATCH] git-rebase.sh: handle keep-empty like all other options
- Date: Mon, 11 Jun 2018 09:08:55 -0700
- From: Elijah Newren <newren@xxxxxxxxx>
- Subject: Re: [PATCH] git-rebase.sh: handle keep-empty like all other options
On Mon, Jun 11, 2018 at 8:16 AM, Phillip Wood <phillip.wood@xxxxxxxxxxxx> wrote:
> On 11/06/18 15:42, Elijah Newren wrote:
>> However, we have a bigger problem with empty commits, in that there
>> are really three modes rather than two:
>> * Automatically drop empty commits (default for am-based rebase)
>> * Automatically keep empty commits (as done with --keep-empty)
>> * Halt the rebase and tell the user how to specify if they want to
>> keep it (default for interactive rebases)
>> Currently, only the first option is available to am-based rebases, and
>> only the second two options are available to interactive-based
> I'm not sure that's the case, my understanding is that for an interactive
> rebase unless you give '--keep-empty' then any empty commits will be
> commented out in the todo list and therefore dropped unless they're
> uncommented when editing the list.
Ah, yes, you are right; I was implicitly thinking about cases where
the commit became empty rather than when the commit started
empty...and mis-read --keep-empty (which as I learned now is only for
> The third case happens when a commit
> becomes empty when it's rebased (i.e. the original commit is not empty), I'm
> not sure what the am backend does for this.
The am backend does not halt the rebase; it simply drops the commit
and says "No changes -- Patch already applied."
It has always seemed jarring and confusing to me that one rebase mode
stops and asks the user what to do and the other assumes. I think
both should have the same default (and have options to pick the
I'm less certain what the default should be, though.
> cherry-pick has
> '--keep-redundant-commits' for this case but that has never been added to
Thanks for the pointer.