6

I sometimes want to pick a range of commits from a different repository. I know two ways to do that.

1.

git checkout myBranch
git cherry-pick begin..end

or

  1. git rebase --onto myBranch begin end

I find the first version easier to remember. However, I read a lot about how cherry-picking is evil compared to merging because it kinda breaks the history. But what I haven't figured out yet is if there is a difference between cherry-picking a range of commits or rebasing them with --onto

I tend to think that there shouldn't be a difference. Am I mistaken?

henry
  • 4,244
  • 2
  • 26
  • 37
Christoph
  • 26,519
  • 28
  • 95
  • 133

3 Answers3

1

Rebasing and cherry-picking are just as 'bad' for merges. They both result in forgetting the IDs of the original commits for the changes you pick up; as a result, later merges may attempt to apply the same changes more than once.

bdonlan
  • 224,562
  • 31
  • 268
  • 324
  • "They both result in forgetting the IDs of the original commits for the changes you pick up; as a result, later merges may attempt to apply the same changes more than once." - This is incorrect – Ana Betts Jul 11 '12 at 08:30
  • 1
    @PaulBetts, how so? The original IDs aren't recorded; there are some heuristics to try to detect and elide double applications, but fundamentally if you merge branches A and A' (where A' is the result of rebasing or cherry picking A onto some other head), you're running the risk of getting extra merge conflicts, and you'll _definitely_ have duplicate commits in the history – bdonlan Jul 12 '12 at 02:34
1

These two commands are equivalent, you're just doing the work that a normal rebase would do to figure out the unmerged commits to replay onto the target branch.

Ana Betts
  • 73,868
  • 16
  • 141
  • 209
  • When you are doing `rebase --onto`? Cherry picking should also detect already applied patches. – Šimon Tóth Jul 11 '12 at 08:38
  • Aren't these two commands different? If I `git checkout myBranch; git cherry-pick begin..end`, then I will advance myBranch forward so that it contains the cherry-picked commits. If I `git rebase --onto myBranch begin end`, then I will advance `end`, and `myBranch` will still be pointing at the same commit it was when I started. – larsks Mar 22 '16 at 18:08
  • Is there a significant difference between the processes that underlie `cherry-pick` and `rebase --onto`? In a recent case, `cherry-pick` unexpectedly had conflicts. I aborted, and tried the equivalent `rebase --onto`... and that worked smoothly – henry May 02 '17 at 13:44
-2

Actually, cherry-picking is less evil in this respect than rebasing. Cherry picking will create duplicates of commits, while rebasing will actually move them (thus rewriting history).

Both are more evil then merging, which in my honest opinion is usually the worst choice.

Šimon Tóth
  • 35,456
  • 20
  • 106
  • 151