5

As my concern here is, I have old commit in my another local branch [contains abc.cpp, def.cpp].

Now after few months I want use those changes, but in my current branch abc.cpp is upgraded. So is it like if I cherry pick then it will integrate changes of old abc.cpp into new abc.cpp [recent working directory copy]?

svick
  • 214,528
  • 47
  • 357
  • 477
Rohan Nemaro
  • 99
  • 1
  • 3
  • 6
  • Note: `git cherry-pick` will soon (git 1.8.5/1.9) be able to cherry-pick "from the previous branch": see [my answer below](http://stackoverflow.com/a/18954079/6309). – VonC Sep 23 '13 at 07:44
  • Possible duplicate of [What does cherry-picking a commit with git mean?](http://stackoverflow.com/questions/9339429/what-does-cherry-picking-a-commit-with-git-mean) – Ciro Santilli新疆棉花TRUMP BAN BAD Feb 22 '16 at 11:32

3 Answers3

8

The git-cherry-pick(1) man page says:

Given one or more existing commits, apply the change each one introduces, recording a new commit for each. This requires your working tree to be clean (no modifications from the HEAD commit).

In plain English, this means that git cherry-pick applies commits from one branch to another, but does not preserve the original history or ancestry from the other branch in the way that a proper merge would do.

Think of it as applying a series of selected patches, rather than a full merge of two branches of history. Obviously, if you tend to make very small, atomic commits then cherry-picking looks exactly like applying a well-written patch. However, since you don't have common ancestors the way you do with merge or rebase, you may have a lot more conflicts to resolve if your commits aren't small and isolated.

Whether or not cherry-picking is a good idea is highly dependent on how you structure your commits. If it doesn't work for you, you can always do things more manually with git format-patch and git apply instead.

Todd A. Jacobs
  • 71,673
  • 14
  • 128
  • 179
4

Yes, that's what it does. cherry-pick is applying a commit (or a range of them) as a patch to your branch (well, almost as a patch).

You might have conflicts (like when you merge branches) since independent modifications have happened on your branches.

Community
  • 1
  • 1
CharlesB
  • 75,315
  • 26
  • 174
  • 199
  • 1
    uh? Like a merge? But it doesn't record the merge like a classic merge do, since it is more like applying a patch. See the warning in http://stackoverflow.com/questions/881092/how-to-merge-a-specific-commit-in-git/881112#881112 – VonC Jun 28 '12 at 12:01
  • I agree the comparison isn't right, I wanted to emphasize that cherry-pick can have to deal with two unrelated modifications, like in a merge – CharlesB Jun 28 '12 at 12:04
  • 1
    Plus, a cherry-pick can use a *range* of commits ;) – VonC Jun 28 '12 at 12:05
  • 1
    Almost: you can mention a cherry-pick isn't *exactly* a patch: http://stackoverflow.com/questions/5156459/what-are-the-differences-between-git-cherry-pick-and-git-show-patch-p1 – VonC Jun 28 '12 at 13:46
2

Note that with git1.8.5/1.9 (Q4 2013), git cherry-pick can now easily cherry-pick "from the previous branch":

Just like "git checkout -" knows to check out and "git merge -" knows to merge the branch you were previously on, "git cherry-pick" now understands "git cherry-pick -" to pick from the previous branch.

See commit 182d7d from Hiroshige Umino (yaotti):

cherry-pick: allow "-" as abbreviation of '@{-1}'

"-" abbreviation is handy for "cherry-pick" like "checkout" and "merge".

It's also good for uniformity that a "-" stands as the name of the previous branch where a branch name is accepted and it could not mean any other things like stdin.

Community
  • 1
  • 1
VonC
  • 1,042,979
  • 435
  • 3,649
  • 4,283