Re: odd behavior with git-rebase

[Neal Kreitzinger <nkreitzinger@gmail.com>]

On 3/26/2012 12:20 PM, Neil Horman wrote:
> On Mon, Mar 26, 2012 at 10:12:48AM -0700, Junio C Hamano wrote:
>> Neil Horman<nhorman@tuxdriver.com>  writes:
>>
>>> I agree, I think perhaps adding an --allow-empty option to the rebase logic, so
>>> that empty commits (or perhaps just initially empty, as opposed to commits made
>>> empty) would be very beneficial.
>>
>> Yeah, that probably may make sense.
>>
> Ok, cool, I'll have a patch in a few days, thanks!
>
IMO, it seems like --allow-empty is an appropriate patch for git-rebase 
(non-interactive), and that git-rebase -i would need a command like 
"k"eep to distinguish which empty commits are not to be discarded and 
which empty commits are ok to discard automatically.  git-rebase -i 
should allow explicit control on a commit by commit basis as opposed to 
blanket rules like "discard all empty commits" or "keep all empty 
commits" that apply to all commits in the rebase-to-do list based on a 
single cli option.

Maybe this is what you plan on doing.  Maybe there is a better command 
name than "k"eep for this.

v/r,
neal