0

I have a commit on a different branch that simply adds a bunch of files in a new directory.

Let's say the commit has id 123456 and it adds a directory called foo full of stuff.

Now in my other branch, from a clean working tree, I do git cherry-pick 123456, expecting it to just add the foo directory.

But no! the cherry pick fails and includes loads of other changes to other files(!) giving me unmerged paths.

Surely the commit you're cherry-picking must contain some stuff you didn't know about/expect, then? Well, no, git show --oneline --name-status 123456 | grep -v foo returns nothing. i.e. all there are no changes that happen to any files outside of foo.

What is happening and how can I cherry pick this commit properly?

artfulrobot
  • 20,637
  • 11
  • 55
  • 81
  • It's not clear from the question whether "foo" was added over HEAD after cherry-pick. If not, try to run cherry-pick with -x flag - maybe you added different commit than the one you had intended. – Vasiliy Jun 28 '13 at 15:10
  • @VasiliyZukanov the `foo` directory did not exist in the working tree at the time of issuing the cherry-pick (is that what you meant?). `-x` is only about the note that accompanies the new commit. I believe it to be an odd git bug (See my answer below). – artfulrobot Jun 28 '13 at 16:48
  • I meant to ask whether `foo` ended up being added to the branch you executed cherry-pick from. Anyway, if upgrading Git resolved your issue - way to go. – Vasiliy Jun 28 '13 at 20:51
  • @VasiliyZukanov you are correct. foo was not in the local branch checked out in the working tree. The intent was that it would be by cherry-picking. – artfulrobot Jul 02 '13 at 21:58

1 Answers1

0

Upgrade git.

BAD: git version 1.7.2.5 (as in Debian Squeeze) - guess Wheezy upgrade will fix it (has v1.7.10)

GOOD: git version 1.7.9.5 (as in Ubuntu Precise)

artfulrobot
  • 20,637
  • 11
  • 55
  • 81