8

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.

Samuel Rossille
  • 18,940
  • 18
  • 62
  • 90
inger
  • 19,574
  • 9
  • 49
  • 54
  • 3
    http://stackoverflow.com/questions/2475831/merging-hg-git-vs-svn or http://stackoverflow.com/questions/2518779/what-are-the-benefits-of-mercurial-or-git-over-svn-for-branching-merging can provide some answers (mostly compared to SVN), and don't forget http://stackoverflow.com/questions/612580/how-does-git-solve-the-merging-problem – VonC Jun 23 '10 at 22:42
  • Thanks, those links are really useful - and I could not find them myself. – inger Jun 23 '10 at 23:15
  • @inger, So close the question as duplicate? – Vi. Jul 07 '10 at 23:17
  • I don't think so, yet. Browsing through those answers, they look more-or-less related and insightful but don't specifically answer the precise same question (unless I missed the obvious, please point me to that then). All those Q-s revolve around the general whole merging experience, and A-s revolve around the git's merge tracking which is great for repeated merges, some tricks, and performance. Some of those a great, but this Q is focusing on small part (the conflict auto-resolution) of that big picture, hoping the get clear and a concise clarification. – inger Jul 13 '10 at 10:49
  • @Vi, VonC's links (which are great), seem more like duplicates of each other. It would be useful to merge:) or distil them into one. For this one, I will try to provide as soon as I get more experience... unless of course some guru does it for us before that. – inger Jul 13 '10 at 10:54
  • 1
    Note: with Git 2.18 (Q2 2018), guiffy will be supported natively by Git as a difftool or mergetool! – VonC May 01 '18 at 21:37

2 Answers2

1

In addition, this more recent thread (2012) details the notion of "auto-resolution" with Git:

My definition for "auto-resolve":
"During a merge, the working tree files are updated to reflect the result of the merge... When both sides made changes to different areas of the same file, git picks both sides automatically, and leaves its up to you to make sure you review those merge results for correctness after git has made the merge commit."

IOW, an "auto-resolve" specifically means that both sides (ours and theirs) made changes to file(a) since the common-ancestor version of file(a), and git picked both sides without raising a merge-conflict.
(The reason I came up with the term "auto-resolve" is because in the git-merge output the term "Auto-merging" can also indicate that only one side (theirs) changed file(a) since the common-ancestor and that git is just "fast-forwarding" theirs file(a) on top of common-ancestor file(a).)

Junio C Hamano raises in answer an important point:

  • know git is stupid and errs on the safe side, punting anything remotely complex;
  • know that textual non-conflicts that occur in the same file have the same risk of having semantic conflict across different files, so singling out "touched the same file but did not conflict" any special is pointless, but in either case, the chance of having such a conflict is small enough that completing the merge (and other merges) first and then checking the overall result is more efficient use of your time, because you have to eyeball the result at least once anyway before pushing it out.

Update 5 and a half years later, May 2018 (Git 2.18, Q2 2018)

"git mergetools" learned talking to guiffy.

See commit 6ceb658 (05 Apr 2018) by Bill Ritcher (``).
(Merged by Junio C Hamano -- gitster -- in commit da36be5, 25 Apr 2018)

mergetools: add support for guiffy

Add guiffy as difftool and mergetool.

guiffy is available on Windows, Linux, and MacOS

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
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.

Clintm
  • 4,505
  • 3
  • 41
  • 54
  • Just for info, what does perforce do now if you change the same line as someone else has changed in parallel? The last time I used p4 it was marked as a conflict and needed manual resolution (similar to git). – CB Bailey Jul 19 '10 at 22:23
  • +1 I'm also curious about that- has anything better been invented than a 3 way diff? There seem to be variances in the algorithms(see Guiffy's whitepaper), but if the same line is changed you stuck with a manual conflict.. unless of course there is some AI-based and strongly language-aware merge tool. – inger Jul 21 '10 at 23:15
  • IMHO 'auto merging non existent' is bit strong. It is there - in the usual sense: eg. when using KDiff3, it has a button 'Auto-merge' and that does more or less what GIT does, sometimes better sometimes worse.. But I was wondering if GIT does/should use its extra history information (e.g. order of commits) for making better decisions? (like it knows where code is pasted from, etc..) – inger Jul 21 '10 at 23:26
  • 1
    I think you're missing the point of merge vs mergetool. merge tries to do a fully automatic merge but it's not trying to do an aided manual merge. That is what mergetool is for; it's not a work around. merge dumps conflict markers in the working tree version to help but it's not the best way to resolve conflicts. You have full versions of base / yours / theirs in the index which is pretty much all the information that any conflict resolution tool needs. p4's visual merge works very well with git as a mergetool. – CB Bailey Jul 23 '10 at 20:40
  • I find some points in your "Update RE: comments" interesting. I tend to agree with whitespace handling issue, it would be great to have an option to ignore those when merging. One option I considered is to plug in a whitespace ignoring wrapper around 'git-merge-file' as merge driver (see config), but finally did that using mergetool (plugged in kdiff3 there which ignores that). This should be supported out-of-the box IMHO. – inger Jul 26 '10 at 11:52
  • Re "merge conflicts in a file... the parts that git says are in conflict .. are larger". That's good to know - but that itself doesn't necessary mean GIT is worse - it might just be more cautious:) (Or perhaps, affected by whitespace differences). I tried tons of merge tools recently and some of them just lie that they know what they are doing, causing more harm than good in some cases. – inger Jul 26 '10 at 11:58
  • Anecdotal, but as @CharlesBailey said, I use p4merge with git, and sometimes p4merge will find no conflicts on a file that git says is conflicted. – Benjol Oct 02 '12 at 10:14