Without arguing the point, can you explain why merge is much, much easier with git? I just want to hear what things you bring up.
Have you tried it? It just works more often than an svn merge.
There are a variety of reasons for that. Git records more data about where the branch originated from, when it's been merged previously, etc. That makes it easier to merge successfully, without conflicts.
Sometimes things just conflict, though, and Git can't do anything about that. Git makes it very easy to get to an un-conflicted state quickly, though, even if it means forgetting the merge all together. svn is slightly less leniant, and if you say "merge", your only options are to fix the conflicts, commit the conflicted files (and be murdered by your coworkers), or throw away your working copy. Not fun.
So to answer your question -- merges no longer cause pain. They either Just Work, or you can revert them easily.
"Have you tried it? It just works more often than an svn merge."
I use it every day, and don't find this to be true. I have to resolve conflicts at about the same rate as I did with Subversion.
"Git makes it very easy to get to an un-conflicted state quickly, though, even if it means forgetting the merge all together. svn is slightly less leniant, and if you say "merge", your only options are to fix the conflicts, commit the conflicted files (and be murdered by your coworkers), or throw away your working copy. Not fun."
Don't be silly. When it comes to conflicts, you can either resolve them, or throw the merge away. Git is no different than Subversion in this regard.
How do you throw them away in svn? If you have changes in your working copy, you can't throw the merge away without throwing those away. Hence the pain.
So don't do that! There's absolutely no need to merge into a working copy with uncommitted changes (unless, of course, you're just looking for ways to break things). Check in your changes, then merge. It's not rocket surgery.
Git doesn't even allow merges into a dirty branch (for the same reason), so I'm not sure what point you're trying to make.
svn does not let you check in changes if your working copy is "out of date". You have to svn update before svn commit, which is the whole problem. (Remember "svn update" is a merge, and can cause conflicts.)
If you're merging a branch into trunk, and your working copy of trunk is out of date, then you're still doing it wrong. Update, resolve conflicts, commit, then merge.
If you're just complaining that sometimes you have to resolve conflicts on update, and that if you don't want to lose your local work by throwing away an update (aka "a merge"), then I have three responses for you:
1) You've got to update trunk someday anyway; suck it up and resolve the conflict.
2) If you're truly terrified of this, work on a branch (aka the Git solution -- which is totally supported in SVN!)
3) If even that doesn't work for you, just copy the files to a backup before you update.
I think you're just inventing problems for the sake of finding problems with a system that you don't like. Subversion is very simple; these situations aren't that hard to figure out.
I could work around the problem, yes, but why bother when Git prevents this situation for me? A version control system shouldn't require me to manually backup the working copy to avoid losing my work.
Basically, svn has no features I want, and it doesn't work as well as git... so there is no reason for me to use it.
If you like svn, that's fine... but you have to realize that it's losing mindshare because most people don't like it as much as git -- often for reasons like the one I mention above.
I think you're just inventing problems for the sake of finding problems with a system that you don't like.
No, this is a real problem that has caused me much annoyance. Obviously I didn't die, but who wants to waste time dealing with inadequate tools?
Subversion is very simple; these situations aren't that hard to figure out.
No, it's not. Read the source code before you write a rebuttal, though -- it's enlightening.
As noted, the merge strategy(-ies) git uses is less prone to causing conflicts-- but TBH, you're always going to encounter some. (DVCSes in general produce fewer conflicts due to various tree merge shenanigans. Darcs and Codeville in particular have more interesting merge algorithms.)
The other huge factor I find that helps with maintaining git release/signed-off/otherwise cherrypicked branches is that git commits tend to be smaller and more discrete (due to, among other things, git stash and cheap history operations) -- I almost never see commits like 'Updates' and then 10-20 files with git, and they're endemic with every SVN/p4 instance I've seen.
It's pretty easy to stash your changes and make a tiny fix with git. Separating things out into discrete changes with SVN (and p4, named changelists don't help that much) usually involves some vimdiff/ediff and patch pain. There are some utils to make it easier, but git makes it trivial.
I like git, and use it, but I'll be honest and say the only thing "killer" about it for me is github.