title: What makes merging in DVCS easy?
body: <p>I read at <a href="http://www.joelonsoftware.com/items/2010/03/17.html" rel="nofollow noreferrer">Joel on Software</a>:</p>
  
  <blockquote>
    <p>With distributed version control, the
    distributed part is actually not the
    most interesting part.</p>
    
    <p>The interesting part is that these
    systems think in terms of changes, not
    in terms of versions.</p>
  </blockquote>
  
  <p>and at <a href="http://hginit.com/00.html" rel="nofollow noreferrer">HgInit</a>:</p>
  
  <blockquote>
    <p>When we have to merge, Subversion
    tries to look at both revisions—my
    modified code, and your modified
    code—and it tries to guess how to
    smash them together in one big unholy
    mess. It usually fails, producing
    pages and pages of “merge conflicts”
    that aren’t really conflicts, simply
    places where Subversion failed to
    figure out what we did.</p>
    
    <p>By contrast, while we were working
    separately in Mercurial, Mercurial was
    busy keeping a series of changesets.
    And so, when we want to merge our code
    together, Mercurial actually has a
    whole lot more information: it knows
    what each of us changed and can
    reapply those changes, rather than
    just looking at the final product and
    trying to guess how to put it
    together.</p>
  </blockquote>
  
  <p>By looking at the SVN's repository folder, I have the impression that Subversion is maintaining each revisions as <em>changeset</em>. And from what I know, Hg is using both <em>changeset</em> and <em>snapshot</em> while Git is purely using <em>snapshot</em> to store the data.</p>
  
  <p>If my assumption is correct, then there must be other ways that make merging in DVCS easy. What are those?</p>
  
  <p><strong>* Update:</strong>  </p>
  
  <ul>
  <li>I am more interested in the technical perspective, but answers from non-technical perspective are acceptable</li>
  <li>Corrections:
  
  <ol>
  <li>Git's <em>conceptual</em> model is purely based on snapshots. The snapshots can be stored as diffs of other snapshots, it's just that the diffs are purely for storage optimization. – <a href="https://stackoverflow.com/users/12166/rafal-dowgird">Rafał Dowgird</a>'s <a href="https://stackoverflow.com/questions/2613525/what-makes-merging-in-dvcs-easy#comment2626335_2613525">comment</a>  </li>
  </ol></li>
  <li>From non-technical perspective:
  
  <ol>
  <li>It's simply cultural: a DVCS wouldn't work at all if merging were hard, so DVCS developers invest a lot of time and effort into making merging easy. CVCS users OTOH are used to crappy merging, so there's no incentive for the developers to make it work. (Why make something good when your users pay you equally well for something crap?)<br>
  ...<br>
  To recap: the whole point of a DVCS is to have many decentralized repositories and constantly merge changes back and forth. Without good merging, a DVCS simply is useless. A CVCS however, can still survive with crappy merging, especially if the vendor can condition its users to avoid branching. – <a href="https://stackoverflow.com/users/2988/">Jörg W Mittag</a>'s <a href="https://stackoverflow.com/questions/2613525/what-makes-merging-in-dvcs-easy#2613595">answer</a></li>
  </ol></li>
  <li>From technical perspective:
  
  <ol>
  <li>recording a real DAG of the history does help! I think the main difference is that CVCS didn't always record a merge as a changeset with several parents, losing some information. – <a href="https://stackoverflow.com/users/148532/tonfa">tonfa</a>'s <a href="https://stackoverflow.com/questions/2613525/what-makes-merging-in-dvcs-easy#comment2624709_2613595">comment</a></li>
  <li>because of <strong><em>merge tracking</em></strong>, and the more fundamental fact that <strong><em>each revisions knows its parents</em></strong>. ... When each revision (each commit), including merge commits, know its parents (for merge commits that means having/remembering more than one parent, i.e. merge tracking), you can reconstruct diagram (DAG = Direct Acyclic Graph) of revision history. If you know graph of revisions, you can find common ancestor of the commits you want to merge. And when your DVCS knows itself how to <strong><em>find common ancestor</em></strong>, you don't need to provide it as an argument, as for example in CVS.<br>
  .<br>
  Note that there might be more than one common ancestor of two (or more) commits. Git makes use of so called "recursive" merge strategy, which merges merge bases (common ancestor), till you are left with one virtual / effective common ancestor (in some simplification), and can the do simple 3-way merge. – <a href="https://stackoverflow.com/users/46058/jakub-narebski">Jakub Narębski</a>'s <a href="https://stackoverflow.com/questions/2613525/what-makes-merging-in-dvcs-easy#2614937">answer</a></li>
  </ol></li>
  </ul>
  
  <p>Check as well <a href="https://stackoverflow.com/questions/2471606/how-and-or-why-is-merging-in-git-better-than-in-svn">How and/or why is merging in Git better than in SVN?</a></p>