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

From: Stephan Beyer <s-beyer@gmx.net>
Date: Aug 23, 2017, 18:06 UTC
Message-ID: <565221dd-b66f-8b88-1bdd-8d0d55c4dc96@gmx.net>
In-Reply-To: <CAGZ79ka-SS8ZyZkp6d=0iNtTtQgh2cAhzJSt4m22F88vb1rbhw@mail.gmail.com>

On 08/23/2017 07:29 PM, Stefan Beller wrote:

Show 11 quoted lines

> 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?

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 :)

It seems empty commits occur *only* if the user wants them to occur (--allow-empty). If they occur unintentionally (for example, by importing some SVN), one can eliminate them using filter-branch or rebase (by commenting out these picks). So it is still unclear to me, why empty commits are handled in such a special way.

Best Stephan

PS: Although -k helps, the original behavior of rebase -i is still a bug.