cherry picking and merge

On Thursday, July 31, 2014, Mike Stump [off-list ref] 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
--