15

When merging branches under source control there is often the issue of a merge conflict with other developers.

I know that we can use vimdiff to diff code changes against source control, but is there also a way we can use vimdiff to help resolve merge conflicts conflicts.

Personally I am interested more in git but it would be useful to understand if there are plugins/techniques for other source control tools/systems.

5
  • Have you ever given Meld a try? Feb 9, 2015 at 19:02
  • 2
    @EricSabelhaus: Is it better than vimdiff at resolving conflicts? This site is about asking/answering questions about vim. Feb 9, 2015 at 20:41
  • It depends on the use case I suppose. If I am working on code that lives remotely, I will most certainly use vimdiff. If I am working locally on my dev machine, I will use Meld, as it provides a feature rich UI to aid the developer in performing complex 3 way merges. Feb 9, 2015 at 20:45
  • 2
    @EricSabelhaus: To me the term feature rich UI is misleading; vimdiff may not have a nice UI it is definitely feature rich. I also find vim a much more productive environment that all GUI editors I have used (but I have used it for a long time and it was a steep learning curve). I more curious if Meld does anything that vim does not do that would make it worth while of even looking. Feb 9, 2015 at 20:51
  • I cant specifically say whether it has a more robust feature set, but it is definitely in the same realm as vimdiff. Feb 9, 2015 at 20:59

1 Answer 1

19

I normally use git on the command line.

But when there is a merge conflict I use Vim to resolve them with (personally I do it with with the fugitive plugin). Note: fugitive is good for a lot of git manipulation from within Vim. My favorite feature is the 3 way diff of a merge conflict.

git supports this in vimdiff via git mergetool. I have installed fugitive but you can set it up manually (Thanks @Jay Thompson).

Manual Set up:

git config --global merge.tool vimdiff
git mergetool <file with conflicts>

The output is slightly different to what is described below (I have not personally used this). But the principle is the same but you have a fourth window at the bottom containing the result.

enter image description here

Set up with Fugitive

vim-fugitive is a git wrapper/integration plugin for Vim; it can do many things, and resolving conflicts is one of them.

<Install the Fugitive Plugin>
vim <file with conflicts>
:Gdiff
  1. View 2 (left) : The code that was on your branch.
  2. View 1 (middle) : The merged code (with conflicts)
  3. View 3 (right) : The code that was merged into your code.

You can now pull and get text from the two other views into the central view (which is going to contain all the manual fixes). Once you have resolved all the conflicts manually simply exit vimdiff

enter image description here

Though you can use :diffget <view number> and :diffput <view number> to pull and push things between views. I don't personally find that very useful. All the code is already in the middle view. So I just like to edit that view manually until the conflict is resolved. Being able to see both versions of the code on either side of my editor window though is extremely useful.

Also a very good demo of its use here

5
  • 1
    If you don't want to use or install Fugitive for some reason, you can also simply set git config --global merge.tool vimdiff and then run git mergetool to start vim in diff mode. Feb 9, 2015 at 18:58
  • Does this support the "diff3" style of merge conflicts, where the "merged common ancestors" is shown?
    – alxndr
    Feb 9, 2015 at 19:39
  • @alxndr: I had not heard of diff3 before. But after a quick google. The output of a merge conflict in git (and other source control I have used) is the same as a diff3 -E. So the images above are generated from files that have these markers in them. Feb 9, 2015 at 20:48
  • Now that I look closely, the first screenshot shows the diff3 style of merge; the middle top pane "BASE" is the common ancestor, which the left and right panes diverged from.
    – alxndr
    Feb 10, 2015 at 5:14
  • 1
    It's important to remember that each of these 4 views is just a buffer. This means you can open another tab (or even stay in the same window) and choose only the buffers you want to look at at any given moment. There's no reason to keep all 4 windows open at once if you're not using all of them.
    – Cody Poll
    Feb 11, 2015 at 11:15

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.