Really, a concrete example that merging in Git is easier than SVN?

Question

Stack Overflow question How and/or why is merging in Git better than in SVN? is a great question with some great answers. However none of them show

Answer 1

From a practical perspective, merging has traditionally been "hard" because of what I call the "big bang merge" problem. Suppose a developer has been working away on some code for a while and hasn't committed their work yet (maybe the developer is accustomed to working in Subversion against trunk, and doesn't commit unfinished code). When the developer finally commits, there is going to be a lot of changes all rolled up into one commit. For the other developers who want to merge their work with this "big bang" commit, the VCS tool isn't going to have enough information about how the first developer got to the point they committed, so you just get "here's a giant conflict in this whole function, go fix it".

On the other hand, the usual style of working with Git and other DVCS that have cheap local branches, is to commit regularly. Once you've done one bit of work that pretty much makes sense, you commit it. It doesn't have to be perfect but it should be a coherent unit of work. When you come back to merge, you still have that history of smaller commits that shows how you got from the original state to the current state. When the DVCS goes to merge this with the work of others, it has a lot more information about what changes were made when, and you end up getting smaller and fewer conflicts.

The point is that you can still make merging a hard problem with Git by making a single big bang commit only after you've finished something. Git encourages you to make smaller commits (by making them as painless as possible), which makes future merging easier.