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 <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 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html