I have a series of commits in a fork that I want to apply or reject one at a time to my fork. Should I use git cherry-pick for this?
A:
Yes. git cherry-pick COMMIT_SHA will allow you to grab a specific commit. You don't need to reject commits, though; just don't cherry pick them.
mipadi
2010-08-12 15:11:00
As a newbie to git, this type of thing confuses me. If I ignore several commits, won't I be forced to cherry-pick them forever? Like, on my next merge, won't it want to merge those ignored commits with any new ones?
Hans
2010-08-12 16:11:06
@Hans: You're right about the next merge, so in general, selective cherry-picking is reserved for cases in which you know you don't want to, and never will, merge the other branch. You should ideally design your branches so that you never have to cherry-pick. See for example this answer to your previous question (and don't miss the links in the comments!) http://stackoverflow.com/questions/3419689/understanding-git-cherry-pick/3420792#3420792 You might also search SO for things about workflow, or post a new question if you'd like to know more.
Jefromi
2010-08-12 16:48:28
@Jefromi - okay, but if you are on master trying to merge origin/master, you basically will need to take it all eventually? Definitely an argument in favor of heavy branching/merging (which of course, is an excellent workflow but I'm having trouble shaking my svn past)
Hans
2010-08-12 20:54:35
@Hans: Yes, if you merge a branch, you're going to get all of it. Of course, you could subsequently revert commits if you had to.
Jefromi
2010-08-12 23:06:42
+3
A:
I'd use an interactive rebase for this:
git rebase -i master fork-branch
When git asks what you want to do with each of the commits, tell it edit for all of them (search and replace pick -> edit). Save and quit, and the interactive rebase will go through the commits, stopping at each to let you do your thing. Do your testing, decide if you want to keep it. If you do, just run git rebase --continue to move on to the next. If you don't, run git reset --hard HEAD^ to reset to the previous commit, throwing away the one you don't want, then move on to git rebase --continue.
If there are commits you know right away you don't want, you can just remove them from the list instead of changing pick to edit. And of course, if I've completely misunderstood, and you don't need to do any testing, then you can pretty much disregard the previous paragraph, and do it all by selectively removing lines.
Jefromi
2010-08-12 15:13:28
@Chas. Owens: Great! Also, you probably knew this, but if you don't want to actually move the fork branch, or if it's a remote branch which you can't really move, you should create another branch at that point to rebase.
Jefromi
2010-08-12 15:54:14
@Jefromi I figured that out rapidly when the git-rebase didn't mention anything about taking a url.
Chas. Owens
2010-08-12 17:47:06