Re: [BUG] rebase -i with only empty commits

From: Junio C Hamano <gitster@pobox.com>
To: Stephan Beyer <s-beyer@gmx.net>
Cc: Stefan Beller <sbeller@google.com>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Git <git@vger.kernel.org>
Subject: Re: [BUG] rebase -i with only empty commits
Date: Wed, 23 Aug 2017 11:29:05 -0700	[thread overview]
Message-ID: <xmqqo9r6yw7i.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <565221dd-b66f-8b88-1bdd-8d0d55c4dc96@gmx.net> (Stephan Beyer's message of "Wed, 23 Aug 2017 20:06:15 +0200")

Stephan Beyer <s-beyer@gmx.net> writes:

> On 08/23/2017 07:29 PM, Stefan Beller wrote:
>> On Wed, Aug 23, 2017 at 8:19 AM, Stephan Beyer <s-beyer@gmx.net> wrote:
>>> On 08/23/2017 04:40 PM, Johannes Schindelin wrote:
>>>> These days, I reflexively type `rebase -ki` instead of `rebase -i`. Maybe
>>>> you want to do that, too?
>>>
>>> That's a very valuable hint, thank you very much!
>> 
>> While -k side steps the original problem, it seems like it would
>> have helped me, too.
>> 
>> Is there any value in discussing turning it on by default?

As we often see on this list, people tend to be blinded by their own
needs and fail to strike the right balance when considering the pros
and cons of a change that may help their immediate desire, I think
there is a value in discussing it, even if the conclusion turns out
that it is not a good idea to change the default.  Rather, make that
"even if" "especially if"---we would reach a reasonable balance
between pros and cons and won't have to repeat the discussion.

> I also wondered why empty commits are "discriminated" in such a way.
> I first thought that if you rebase branch A onto B but branch A and B
> contain commits with the same changes, then these commits would become
> new empty commits instead of simply being ignored. But I just checked
> this theory and it is now falsified :)

If you add an identical patch on each of your two toy example
branches and try to rebase one over the other, an early logic that
culls the set of commits to replay based on patch ID will remove
them so you would not even see "it has become empty".

I think you can redo your example by having two consecutive commits
on one branch, and then make one commit on the other branch whose
effect is those two commits' effect combined.  Then rebase the
latter on top of the former.  "cherry-pick A..B" seems to be aware
of this more interesting case and allows you to control the
behaviour by having --keep-redundant-commits and --allow-empty as
two separate options, but it seems there is no similar provision in
"rebase".