Re: odd behavior with git-rebase

From: Jeff King <peff@peff.net>
Date: Mar 23, 2012, 19:54 UTC
Message-ID: <20120323195455.GB15063@sigill.intra.peff.net>
In-Reply-To: <20120323185205.GA11916@hmsreliant.think-freely.org>

On Fri, Mar 23, 2012 at 02:52:05PM -0400, Neil Horman wrote:

Show 10 quoted lines

> 	I hit a strange problem with git rebase and I can't quite decide if its
> a design point of the rebase command, or if its happening in error.  When doing
> upstream backports of various kernel components I occasionally run accross
> commits that, for whatever reason, I don't want/need or can't backport.  When
> that happens, I insert an empty commit in my history noting the upstream commit
> hash and the reasoning behind why I skipped it (I use git commit -c <hash>
> --allow-empty).  If I later rebase this branch, I note that all my empty commits
> fail indicating the commit cannot be applied.  I can of course do another git
> commit --allow-empty -c <hash>; git rebase --continue, and everything is fine,
> but I'd rather it just take the empty commit in the rebase if possible.

I think it is even odder than that. If you use plain rebase, the empty commits are silently omitted. If you do an interactive rebase, you get the "could not apply" message (and just doing a "continue" creates some funny error messages and ends up omitting the commit).

I think both of these are bugs. In the first case, the empty commit appears to be already applied, because it does nothing. But if somebody bothered to create an empty commit in the first place, they probably want to keep it, and we should special-case it.

As you've probably guessed, empty commits are not all that common, and I think this area of git is not well-tested.

-Peff