On Thursday, July 31, 2014, Mike Stump <mikestump@xxxxxxxxxxx> wrote: > > Cherry picking doesn’t work as well as it should. I was testing on git version 1.7.9.5. > > Put in a line in a file, call it: > > first version > > then cherry pick this into your branch. Then update on master and transform that into: > > second version > > then, merge that branch back to master. Death in the form of conflicts. The problem is that cherry-picked commits lack the metadata that git merge could use to avoid this spurious conflict report. The reflog has the metadata in question, but there's no guarantee that that reflog will be available where you do the merge. (IMO this is another reason to want branches as objects, so such ancillary information can be recorded somewhere, but in a way that can get dropped if desired and without changing commit hashes, but I digress.) If you always rebase your commits on top of the upstream, then this problem goes away. You can't always rebase your commits on top of the upstream though, but wherever possible it's the best course of action for this and other reasons. Nico -- -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html