0

I used to do conflict resolution with P4merge. I found it OK but I didn't pay any attention to how it does the job under the hood. Until very recently I realized that it tries to make the merge by itself. As a result it doesn't show the same conflicts as git does and that frustrated my manager (like in let's switch back to clearcase frustrated).

The question is: git adds annotations to a file that can't merge similar to these

<<<<<<< HEAD
    this code
=======
    the other code
>>>>>>> feature/branch-name

Is there a graphical tool that reads these annotations and then gives you the option to keep the one or the other and then remove the annotations?

The tool should be for Linux and preferably free but since the organization will take care of the cost, it can be paid as well.


UPDATE: kdiff3 trial

Unfortunately kdiff3 doesn't respect annotations either. First of all the setup didn't work but no big deal, I've changed the .gitconfig to

[mergetool "kdiff3"]
     cmd = /path/to/kdiff3 $BASE $REMOTE $LOCAL -o $MERGED

and it worked. But then kdiff3 reported this:

kdiff3 output

Not exactly what I expected: I had 4 conflicts and the tool says there are 2. Also the Nr of automatically solved conflicts message makes me think that kdiff3 applies its own merging algorithm, which is the opposite of what we want.

3
  • By default kdiff3 automatically resolves conflicts based only on whitespaces issues. But you have a lot of options to configure in its settings if you want to change its behavior. See stackoverflow.com/a/15813064/6368697 : "if you really want to disable any automatic resolving, just add --qall to the kdiff3 command line". Also you said you have 4 conflicts and the tool says 2 but without seeing what you are seeing it is difficult to understand your situation and why the discrepancy. Apr 10, 2018 at 16:11
  • @PatrickMevzek I don't want kdiff3 or any other tool to resolve conflicts on its own. I want it to respect the conflicts that git produces rather than redoing the merge. Apr 10, 2018 at 16:14
  • See my edited comment. Add --qall. From help: "Don't solve conflicts automatically.". I always thought it is one of its strength, so I do not have to loose time on trivial conflicts, but at least you have the option to disable it. YMMV. Apr 10, 2018 at 16:16

2 Answers 2

1

kdiff3 can handle this. It is a generic diff viewer and merge tool (you can use also outside of any VCS, for example to compare directories content).

If using git you can have this in your gitconfig:

[mergetool "kdiff3"]
    trustExitCode = false
    keepBackup = false

[merge]
    tool = kdiff3
    conflictstyle = diff3

so that git mergetool after a failed merge will launch the tool automatically for you.

kdiff3 will try to merge for you the trivial stuff and will present you a 4 panes window to resolve the non trivial stuff, based on git merge failures annotations.

The top row is split in 3 areas to show you:

  • A = LOCAL: this is the file content from your local branch
  • B = BASE: this is the file content as common ancestor, how it was before any of the changes in either LOCAL or REMOTE
  • C = REMOTE: this is the file content from the branch your are merging from and into your branch (as displayed in LOCAL)

The bottom row is an editable text being the result of the merge, based on your choices.

You can either select options A, B or C to apply either the changes in A, B or C in the resulting merge. Or you can edit things yourself in the bottom text editor.

See this screenshot: http://kdiff3.sourceforge.net/doc/screenshots.html#dirmergebigscreenshot

kdiff3 is free software and will work everywhere KDE works. The interface is a little dated but it works.

Other options:

  • meld, see http://meldmerge.org/ ; the UI is prettier than kdiff3 but I found it less complete feature-wise for my needs
  • if you have a look at git-config under the merge.tool key you will see a list of softwares git knows about to resolve merges. This could give you ideas on things to test to find out the best one for you. On my installation, the list is: araxis, bc, bc3, codecompare, deltawalker, diffmerge, diffuse, ecmerge, emerge, examdiff, gvimdiff, gvimdiff2, gvimdiff3, kdiff3, meld, opendiff, p4merge, tkdiff, tortoisemerge, vimdiff, vimdiff2, vimdiff3, winmerge, xxdiff
4
  • Thanks for the thorough answer. We've tried meld but we weren't happy with it. We also tried IntelliJ's merging with the same result. I can't test quickly kdiff3 as I'm on RHEL, with Gnome and a local repository without Qt. It will take some time before I give feedback. Apr 6, 2018 at 10:14
  • If you can, try a VM or a container maybe to at least have a look. Or start a computer with some LiveCD of a distribution having it. Apr 6, 2018 at 13:16
  • That's what I've done in the end. I don't want to be disrespectful but unfortunately that's a -1 answer -although I don't intend to downvote. kdiff3 doesn't seem to respect annotations, the screenshot doesn't prove it and meld performs its own merge as well. So unless I've missed something in kdiff3's configuration, that's not a correct answer. Although I've learned of conflictstyle = diff3 which I was ignoring until now. Apr 10, 2018 at 14:07
  • @SteliosAdamantidis My experiences with kdiff3 do not match yours, I am sorry. From my use, it always worked correctly with git, doing all merge possible by itself and leaving me with the ones too complicated to be solved automatically. Note also that I did not have to configure git the way you needed to do, so maybe you are on a very different setup. Sorry if it does not work for you, I hope you will then get other better answers. Apr 10, 2018 at 16:07
0

If you are open to learning how to use Emacs or Vim, they offer exactly what you want thanks to ediff and vimdiff respectively:

  • a graphical interface with clear color highlighting of the alternative versions of conflicts (but without removing any of the Git conflict markers)
  • keybindings to easily jump from one conflict to the next
  • keybindings to easily select one or the other version for each conflict

They aren't running any algorithms: Git does the job. They simply are interfaces making it nicer to resolve the conflict.

To use ediff, open your file in Emacs and run smerge-ediff or set Emacs to launch it automatically. See this Emacs Stack Exchange answer for an image of the interface and details of the keybindings. An alternative is to install the magit package which uses ediff though magit-ediff.

To use vimdiff, you can set it as your merge tools in Git config. The interface is quite similar.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.