On 3/23/2012 1:52 PM, Neil Horman wrote:
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?
FWIW, I'm not sure what you mean by "backport", but IMHO backporting a
critical fix to an earlier version seems by nature to be a cherry-pick
operation as opposed to a rebase operation. A rebase implies "I want
everything" -- that doesn't sound like a backport. A cherry-pick
implies "I only want certain things" -- that sounds like a backport.
Maybe your really using rebase to cherry-pick several commits. Using
your technique of "empty commit placeholders", it seems you could end up
with quite a lot of "empty" commit placeholders which doesn't seem to
make much sense. Why would you want a bunch of empty commit
placeholders in your older version bugfix history saying "I didn't want
this, but its in the newer version." (who cares?). Isn't having the
stuff you do want recorded as commits enough to make it clear what you
brought over? You could even edit the "cherry-picked" (or rebased)
commit messages to document the sha1 of the commit being cherry picked
from the newer version. That seems to make more sense to document what
you did, as opposed to documenting what you didn't do.
I'm not a git expert or a kernel developer, but find this subject
relevant and interesting. Our "New" system was forked from our "old"
system. We bring over fixes/features from "old" system to "new" system.
"New" system hast limited field testing accumulated, and gets
features/fixes from "old" system which has extensive productional
testing ongoing. When doing so, many "old" system changes are not
wanted as they are irrelevent to the "new" system. Having an empty
commit for them makes no sense.
Food for thought. Maybe my cooking as bad. Maybe I'll learn a new recipe.
v/r,
neal
--
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