I have the following repository layout:
When it comes to a range of commits, cherry-picking
is was not practical.
git cherry-pick" learned to pick a range of commits
cherry-pick A..B" and "
cherry-pick --stdin"), so did "
git revert"; these do not support the nicer sequencing control "
rebase [-i]" has, though.
In the "
cherry-pick A..B" form,
Ashould be older than
If they're the wrong order the command will silently fail.
If you want to pick the range
D (inclusive) that would be
See "Git create branch from range of previous commits?" as an illustration.
This assumes that
Bis not a root commit; you'll get an "
unknown revision" error otherwise.
Note: as of Git 2.9.x/2.10 (Q3 2016), you can cherry-pick a range of commit directly on an orphan branch (empty head): see "How to make existing branch an orphan in git".
Original answer (January 2010)
rebase --onto would be better, where you replay the given range of commit on top of your integration branch, as Charles Bailey described here.
(also, look for "Here is how you would transplant a topic branch based on one branch to another" in the git rebase man page, to see a pratical example of
git rebase --onto)
If your current branch is integration:
# Checkout a new temporary branch at the current location git checkout -b tmp # Move the integration branch to the head of the new patchset git branch -f integration last_SHA-1_of_working_branch_range # Rebase the patchset onto tmp, the old location of integration git rebase --onto tmp first_SHA-1_of_working_branch_range~1 integration
That will replay everything between:
~1): the first commit you want to replay
integration" (which points to the last commit you want to replay, from the
tmp" (which points to where
integration was pointing before)
If there is any conflict when one of those commits is replayed:
git rebase --continue".
git rebase --skip"
git rebase --abort" (and put back the
integrationbranch on the
integration will be back at the last commit of the integration branch (that is "
tmp" branch + all the replayed commits)
With cherry-picking or
rebase --onto, do not forget it has consequences on subsequent merges, as described here.
A pure "
cherry-pick" solution is discussed here, and would involve something like:
If you want to use a patch approach then "git format-patch|git am" and "git cherry" are your options.
git cherry-pickaccepts only a single commit, but if you want to pick the range
Dthat would be
B^..Din git lingo, so
git rev-list --reverse --topo-order B^..D | while read rev do git cherry-pick $rev || break done
But anyway, when you need to "replay" a range of commits, the word "replay" should push you to use the "
rebase" feature of Git.