Re: odd behavior with git-rebase

On Fri, Mar 23, 2012 at 3:54 PM, Jeff King [off-list ref] wrote:

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

quoted

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

Coincidentally I ran into this same behavior this week.  But what
bothered me about it was the messages git gave me.  The empty commit
gave me cherry-pick hints instead of rebase ones, including advising
me to "use 'git reset'" to resolve the problem if I don't want this
commit after all.

$ git rebase -i HEAD~10
...
The previous cherry-pick is now empty, possibly due to conflict resolution.
If you wish to commit it anyway, use:

    git commit --allow-empty

Otherwise, please use 'git reset'
# Not currently on any branch.
nothing to commit (working directory clean)
Could not apply d513504... Some commit message


I'm not sure if this is the norm or if it's a result of some other
things I did in this sequence.  But I've seen it several times now.
I've only tested it on 1.7.10 versions, including RC2.

Phil