If you're referring to the `git merge` command then the actual things they do are quite different.
In svn it applies specified changes to your working copy, while in git it either fast-fowards branch-a to branch-b if applicable, or finds a common ancestor for the commits and creates a 'merge commit' so the commit history won't be linear (it will branch and re-converge). If all the branches are local, you can also use 'rebase' and that will make the history a little cleaner (well, linear at least).
The chapter on branches in the pro git book is enlightening:
Merging is still a pain with git. Especially if you have to deal with xib or xcodeproj files (for iPhone/Mac dev). To the point where the usual process I see amounts to "don't touch this file -- I'm working with it (and don't want to lose any work)." instead of dealing with a merge that is almost guaranteed to make someone lose work.
Comments
I hadn't realized git incorporated the much-maligned svn merge as a feature.
If you're referring to the `git merge` command then the actual things they do are quite different.
In svn it applies specified changes to your working copy, while in git it either fast-fowards branch-a to branch-b if applicable, or finds a common ancestor for the commits and creates a 'merge commit' so the commit history won't be linear (it will branch and re-converge). If all the branches are local, you can also use 'rebase' and that will make the history a little cleaner (well, linear at least).
The chapter on branches in the pro git book is enlightening:
http://progit.org/book/ch3-1.html
Merging is still a pain with git. Especially if you have to deal with xib or xcodeproj files (for iPhone/Mac dev). To the point where the usual process I see amounts to "don't touch this file -- I'm working with it (and don't want to lose any work)." instead of dealing with a merge that is almost guaranteed to make someone lose work.