Is git's merge conflict resolution more efficient than other SCMs and merge tools?

Question

Is git's merge conflict resolution inherently more efficient than other SCMs (CVS,Subversion,etc.), and also standalone merge tools? If so, why?

Clarification: here I'm more interested in the algorithm itself - is it any different from a plain diff3 method?
Some tools claim to be smarter in that(e.g. Guiffy), is it worth plugging one in as a git merge tool? Is git any smarter in figuring out pieces of text moved within or across files ? (rather than reporting noisy conflicts.. I had a vague impression of that from Linus' talk).

Background: just did a huge merge using git-svn which resulted in half the conflicts than I got with plain svn merge (first merge with no tracking) .. so I'd like to understand why.

---

The are similar Qs/As around but they are more about the big picture of the process, and how merging fits in that more naturally. To that end, git being 'optimised for merges' (as opposed to only branching), does it actually mean:

1. less manual conflicts -- better auto-resolution algorithms (eg. renaming is handled nicely)
2. safer operation -- auto-resolution leaves more/only real conflicts and less false alerts
3. faster operation -- say, due to the lean & mean object model
4. better tooling -- which makes the experience less painful, e.g. DAG-based merge tracking, mergetool, history query/visualisation, stash, rebase,etc...
5. something else
6. a combination of the above

? Now, I'm mostly interested in 1 & 2.

Answer 1

I would love to be proven wrong on this answer but... coming from perforce... this area of git is a bit under developed.

1. Auto merging in git is non-existant. The latest version has basic support for performing a merge using your changes or their changes but that's it. Basically if you edit a portion of a file and someone else edits the same portion of a file... you're on your own for merge resolution. The diff3 format is available (3-way merge) but I believe a unified diff format is the standard. I actually use araxis as the merge tool and have it setup to use 3 way merge when running "git mergetool". Coming from perforce though... I feel like git is way behind in this area.

2. N/A

Update RE: comments

I haven't dug deep enough into exactly what git thinks is a conflict and exactly what p4 thinks is a conflict but here's what I've experienced in both.

• Git does not ignore white space when doing a merge... although there is talk about this in the future for git. p4 can do this now. Not ignoring white space is a major pain unless everyone on the team agrees on using spaces or tabs and if you'd like to change the indention of a file... (e.g. adding an xml node around other nodes) then this gets old fast.
• I feel like when I come across merge conflicts in a file... the parts that git says are in conflict using it's unified diff format are larger. When it's only a portion of one line that's changed it will mark larger portions as modified and you need to visually hunt down the changes between the two areas of of the unified diff output. You can kind of get around this using a mergetool though. p4 is able to auto resolve conflicts even if editing the same line.
• If you're merging long lived topic branches then you're in for a real treat. Without rerere turned on (which is off by default) git will forget that you've already merged that file that was in conflict a week ago and will ask you to merge it again. p4 does this with ease

My answers here are a bit subjective... but I do sorely miss the merging that I had with perforce.