<story><title>How Git cherry-pick and revert use 3-way merge</title><url>https://jvns.ca/blog/2023/11/10/how-cherry-pick-and-revert-work/</url></story><parent_chain></parent_chain><comment><author>juped</author><text>You can set the config option `merge.conflictStyle` to `diff3` to see all three inputs to a merge conflict (left, base, and right, rather than just left and right); this lets you actually resolve them, because you can see the changes left made to base, and the changes right made to base, and make both changes, rather than having to guess at what&amp;#x27;s going on.&lt;p&gt;I wish this were the default. (It&amp;#x27;s not broadly because it displays certain arcane recursive merges in a really bizarre way; see the mailing list for discussion.)</text></comment>
<story><title>How Git cherry-pick and revert use 3-way merge</title><url>https://jvns.ca/blog/2023/11/10/how-cherry-pick-and-revert-work/</url></story><parent_chain></parent_chain><comment><author>forkerenok</author><text>Very insightful read, thanks for sharing!&lt;p&gt;I remember many cases when I was cherry-picking things on a slightly changed (with overlaps) HEAD and it just worked. So I had this intuition that it&amp;#x27;s smarter than a flat patch, but had no idea that it is a legit 3-way merge!&lt;p&gt;Slightly OT: I noticed that the git source code links in the article are referencing master branch. I think it would be better for longevity to fix a commit hash.</text></comment>