4

I've got two branches in git, master/ and 1.7/. I backport some fixes from master/ into 1.7/, using cherry-pick. (I'm not using merge because I only want some of the changes.):

$ git checkout 1.7
$ git cherry-pick -x <initial commit SHA>..<master change 2 SHA>

Then later on, I merge 1.7/ back to master/, because I want all changes that have gone into 1.7/ (except for the cherry-picks themeselves) to be merged back to the mainline:

$ git checkout master
$ git merge 1.7

My problem is that this re-commits the cherry-picks (originally from master/) into master/ again:

$ git log --oneline
8ecfe22 Merge branch '1.7'
fe3a60d master change 2 (cherry picked from commit f5cca9296e45d5965a552c45551157ba
9c25f53 master change 1 (cherry picked from commit 8fae2a68a356f5b89faa8629b9a23b23
f5cca92 master change 2
8fae2a6 master change 1
ffa10bf initial commit

In my real repository it even caused merge conflicts.

So my question is, can I avoid this (and if so, how)?

The full list of commands to reproduce this behavior:

$ git init
<create Dialog.js file>
$ git add Dialog.js
$ git commit -am "initial commit"
$ git branch 1.7

<edit Dialog.js file>
$ git commit -am "master change 1"
<edit Dialog.js file>
$ git commit -am "master change 2"
$ git log

$ git checkout 1.7
$ git cherry-pick -x <initial commit SHA>..<master change 2 SHA>

$ git checkout master
$ git merge 1.7
$ git log
Bill Keese
  • 1,792
  • 14
  • 29

1 Answers1

2

When you cherry pick, unless you are using the fast forward option -ff, you are creating new commits and when you merge back, git has to merge in those commits, even though they may effectively be no-ops.

Rebase might help you here, instead of merge:

git rebase master 1.7

and then now, merge the branch ( if needed.)

Cherry-pick is used best when you want to get small changes from a branch that you are otherwise discarding. Your workflow should be based on merge or rebase as appropriate.

manojlds
  • 290,304
  • 63
  • 469
  • 417
  • Yes, I can imagine rebase working, although in the git community, calling rebase on a branch is considered a mortal sin. Is there another approach? Could I use "git merge" to move changes from master/ to 1.7/, but somehow filter which changes it merged? Like a -i option similar to rebase -i? And if I did do that, would git remember which changes came from master/ and not try to re-merge them back into master later? – Bill Keese Dec 22 '11 at 03:56
  • Oops, above I meant to type "calling rebase on a *public* branch is considered a mortal sin". – Bill Keese Dec 22 '11 at 04:21