From: Neil Horman Date: Fri, 23 Mar 2012 18:52:05 GMT Subject: odd behavior with git-rebase Message-ID: <20120323185205.GA11916@hmsreliant.think-freely.org> Hey all- 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 --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 ; git rebase --continue, and everything is fine, but I'd rather it just take the empty commit in the rebase if possible. I know that git cherry-pick allows for picking of empty commits, and it appears the rebase script uses cherry-picking significantly, so I'm not sure why this isn't working, or if its explicitly prevented from working for some reason. anyone have any insight? Thanks & Regards Neil