26

As the title suggests, I am curious as to why so many people tout Git as a superior alternative to branching/merging over SVN. I am primarily curious because SVN merging sucks and I would like an alternative solution.

How does Git handle merging better? How does it work?

For example, in SVN, if I have the following line:

Hello World!

Then user1 changes it to:

Hello World!1

then user2 changes it to:

Hello World!12

Then user2 commits, then user1 commits, SVN would give you a conflict. Can Git resolve something simple as this?

Jon Seigel
  • 12,251
  • 8
  • 58
  • 92
Alexander
  • 269
  • 1
  • 3
  • 3

2 Answers2

30

That is called on merge with conflict, and no VCS will ever solve that for you.
You will have to manually solve the merge yourself.

As mentioned in Why merging in git is better than SVN, the actual difference is in the history recording of commits:

That allows Git to remember what has already merged, reducing considerably the conflicts occurrences.

DAG

So, when it comes time to do merge from 5b over to the (a) branch, we can use information in the DAG to know that 3b and 2b are already done

So it is the merge workflow that Git will handle much more gracefully than SVN:
See Merge Git vs. SVN for concrete examples.

kostix
  • 51,517
  • 14
  • 93
  • 176
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • @VonC: But yours has pretty picture, and link to answer about SVN's inability to merge, which I couldn't really provide any specifics for. +1! – Cascabel Apr 22 '10 at 17:24
  • @Jefromi: yes, I like pretty picture ;) I just added a reference to another SO question which illustrates nicely the difficulties (for SVN) to manage the "more complex merge patterns" you allude to in your answer. – VonC Apr 22 '10 at 17:28
  • @John: I didn't: Eirk Sink did include it, in his website http://www.ericsink.com/. You will find other instances of those diagrams in http://www.ericsink.com/entries/dvcs_dag_1.html. Erik mentions in http://www.ericsink.com/entries/dvcs_dag_2.html "Several people asked me how I drew those really cool diagrams": "My DAG pictures were drawn by SourceGear's graphic artist, John Woolley, who also did all the artwork for the Evil Mastermind comic books. John is doing the layout and illustration work for my upcoming source control book as well." – VonC Apr 23 '10 at 04:17
  • 1
    _That allows Git to remember what has already merged_. However, Subversion does track what has already been merged. Subversion merges do have issues, but not remember what has been merged isn't one of them. – David W. Sep 02 '13 at 23:18
  • @DavidW. I believe that is DVCS tools (Mercurial, Git, ...) made so much progress from 2005 to now, this is precisely because SVN lost initially track of what is important in a version control tool: SVN made branching easy, but merge hard. True, since SVN 1.5 (2008), the metadata `svn:merge-info` helps alleviate that... if you do the merge correctly ;) See http://stackoverflow.com/a/12372645/6309 : "Merge from the root of your project only, and not individual branches and files", and so on. – VonC Sep 03 '13 at 05:30
  • @DavidW. That last link illustrates that 4 to 5 years later, the all `merge-info` is still 'hackish'. Meanwhile, people move on, unzip a msysgit on their PC and start adding stuff to a repo in 30 seconds flat. No process. No server. No nothing. One push away to a GitHub or BitBucket repo. And the merge works. – VonC Sep 03 '13 at 05:32
  • 1
    @VonC The problem with tools like Git is that they can add complexity to the process (you now have two repos), and make much of that process invisible. While users have their private repos, no one can see what they're doing. Git also can encourage users to work separately from others. I am working in my own cave. I've seen where DVCS work well and where they can fail miserably. Merging might be *easier*, but then people may do it a lot less. After all, I don't have to deliver my stuff until the release. Let me get it perfect. – David W. Sep 03 '13 at 11:11
  • "Merging might be easier, but then people may do it a lot less. After all, I don't have to deliver my stuff until the release. Let me get it perfect.": this isn't git-specific: you can adopt a "bad" workflow with any (centralized in your own branch, or decentralized in your own repo) VCS tool. – VonC Sep 03 '13 at 11:17
  • 1
    @VonC Git and SVN have different strengths and weaknesses. However, what it comes down to is that Subversion **does** track merging, and won't merge things twice. You can't simply claim that Subversion doesn't. – David W. Sep 03 '13 at 13:35
  • @DavidW. you are right: SVN won't merge things twice. The current DVCS won't either. – VonC Sep 03 '13 at 14:30
  • @VonC I like Git. However, I've seen SVN vs. Git turn into another religious war. People simply say things that aren't true (SVN doesn't do merges or it only does two way merges). As a CM, there are times I recommend using Git and there are times I recommend using SVN. SVN is simpler to use than Git and SVN hooks work better. However, Git works better if you have a site where you don't want to track all users at the top level or you have small high powered and rapid development and you don't want the central repo getting in the way. Or, you don't even have a central repo. – David W. Sep 03 '13 at 16:12
  • @VonC: Hello Sir, could you possibly help me out with my question [here](http://stackoverflow.com/q/36157555/3287204) ? Thank you ... :) – Yash Sampat Mar 23 '16 at 05:53
  • @Y.S. I have no access to SVN to test it out right now. I would suggest trying to merge through command-line instead and see if you get a more complete error message. – VonC Mar 23 '16 at 07:52
  • @DavidW., pardon my ignorance (I'm not a native speaker), but what does "CM" stand for? The closest thing I was able to come up with by searching is the "configuration manager". – kostix Aug 13 '18 at 08:25
18

The specific conflict you mention is always unresolvable. There's simply no way for a merge tool to know which version should be kept.

Git is probably better than SVN at dealing with resolvable conflicts, though. Its primary merge strategy is recursive, which finds the common ancestor of two commits changing the same file and does a three-way merge. It also has some built-in capability for recording and reusing conflict resolutions (git-rerere) and a variety of other merge strategies for special cases.

Git's advantage in merging is that it's part of the history. A merge commit is a commit with two parents. Git's model of history (a directed acyclic graph) expects there to be commits like this. This means that further merges in the future work exactly how they should. Always. (Yes, there are sometimes conflicts, but they're real conflicts, not an inability to handle the merge.)

SVN, on the other hand, just tries to track where merges occurred, but its model is still inherently linear. The history still just has a single string of commits, with merge tracking information providing extra help. From what I've heard, SVN can't always handle more complex merge patterns correctly. (One example is a reflective merge - merging A into B then B into A.)

Cascabel
  • 479,068
  • 72
  • 370
  • 318
  • I was first! For 50 seconds!... But let's face it, your answer is much more detailed and precise ;) +1 – VonC Apr 22 '10 at 17:23