On Sun, Jan 23, 2011 at 08:10:00PM -0800, Zach Bailey wrote:

> I am leading a subversion to git migration where I work and things are
> going OK so far. One weird thing we are noticing is when we're cherry-
> picking old commits from the an old subversion integration branch into
> several separate new topic branches each for a previous feature that
> was in progress, we're seeing weird results.
> For instance, here is a file diff from a commit I am cherry picking:
> diff --git a/path/to/file b/path/to/file
> index b0cd7f5..21992d7 100644
> However when I perform the cherry pick, git is changing other parts of
> the file that weren't touched and don't match up to the above diff.
> What I was expecting to happen would be as if I had manually created a
> patch out of the diff from the specified commit and then applied that
> patch to the current branch.
> My understanding is a cherry pick essentially takes the changes made
> in a particular commit and then applies those same changes to the
> files in the current working tree.
Your expectations about how cherry-pick works are correct.

> So, why would I be seeing other changes? What i'm afraid is happening
> is git is doing a diff between current commit and the commit specified
> in the cherry-pick and applying those changes instead, which is
> definitely not what I want.
> Where am I going wrong?
The only immediate idea I can come up with is that you mistakenly pass
cherry-pick more than one argument designating a commit, that is,
something like
$ git cherry-pick b0cd7f5 21992d7
instead of just
$ git cherry-pick 21992d7

Also, a weird idea, but may be you somehow manage to see the wrong diff?
If you intend to cherry-pick a commit C, the changes it introduces can
be seen using `git show C`.

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to