On Thursday, July 31, 2014, Mike Stump <mikest...@comcast.net> wrote:
> Cherry picking doesn’t work as well as it should. I was testing on git
> version 126.96.36.199.
> 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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html