samoshkin / vim-mergetool Goto Github PK

How would one handle a merge conflict like the following, where I would want to keep both changes?

<<<<<<< ours
  /** An extensive
   * comment. */
  bool some_boolean;

||||||| base
=======
  /** Some other
   * multiline
   * comment. */
  bool another_variable;

>>>>>>> theirs

Opening that file and running :MergetoolStart gives me the following:

My vim-mergetool configuration:

let g:mergetool_layout = 'mr'
let g:mergetool_prefer_revision = 'local'

Great plugin! It'll be easier to use if we add a Vim doc for use with the ":help" command.

When there is a conflict in the one branch only (pulling conflicting commits), this plugin does not work. I will get Conflict markers miss common base revision. Ensure you're using 'merge.conflictStyle=diff3' in your gitconfig in my footer.
I've already created a Git conflict simulation for my students which simulates a conflict. It can be used to further improve this plugin.
Here is the screenshot of my vim after trying the mergetool.

The current implementation of MergetoolDiffExchange for example, does not work for a situation where both sides of the working window are other valid windows.
For example, when one has BMR layout and is in the BASE window can normally put the diff in the MERGE window by MergetoolDiffExchangeRight. However, in the MERGE window, the diff from the BASE windo (left side) is not got with MergetoolDiffExchangeLeft, instead MergetoolDiffExchangeRight does the job (which is the opposite of what we intend).

Tracking the issue, I realized the DiffExchange function here is problematic. On MergetoolDiffExchangeLeft in MERGE window (BMR layout), it reverses the direction (which was a good thing in putting the diff from B to M with MergetoolDiffExchangeRight) and gets the diff from the REMOTE.
I believe we should not determine the direction by reversing it as it may consider another window which does not have to do anything with what we want (R in the BMR for example). We already know both exchange parties.
I have solved this issue locally and will send a pull request.

Could you add :help documentation?

I get this when I run the command git mergetool I don't know if this is because it tries to run the command MergetoolStart is available or other thing. 😞

Do you have an Idea if it is something wrong I have configured or some of the package. o.0

vim-mergetool only supports scms that name their temp files BASE, REMOTE, LOCAL.

Svn names the files something like this:

file.cs.r404563
file.cs.r404217
file.cs
file.cs.mine

You should be able to start vim with something like this:

gvim -f -c "MergetoolStart" "%MERGED%" "%BASE%" "%LOCAL%" "%REMOTE%"

Requiring a specific order would make elements 0:3 of argv() those arguments in that order.

I think it's better to provide an scm-agnostic way to map the files, so maybe a variable g:mergetool_arg_order = 'mblr' that sets up those files could work.

When loading a revision into a new buffer, this plugin will do set nomodifiable on said buffer, which means you can't use :diffput to resolve conflicts. There are obviously ways of working around it, but being able to use :diffput would be preferable since the folding behavior is dependent on the diffs.

Just want to make it look like IntelliJ mergetool
let g:mergetool_prefer_revision = 'BASE' seems not to work.
Thanks you!

MacOS: 10.14.6
vim 8.1

error:

Trying to merge loader.lua and show L or R in a diff and I get errors in those buffers.

:edit loader.lua
:MergetoolStart
:MergetoolToggleLayout LmR

LOCAL:

fatal: Not a valid object name :2:loader.lua

REMOTE:

fatal: Not a valid object name :3:loader.lua

Looks like the issue is that mergetool is assuming merging is started at the root of the repository, but when starting mergetool while editing, it is not.

Probably s:mergedfile_name needs to be relative to the .git.

Tested on 0275a85

I want equal sized windows whenever mergetool lays out the windows.

function s:on_mergetool_set_layout(split)
    wincmd =
endfunction
let g:MergetoolSetLayoutCallback = function('s:on_mergetool_set_layout')

This works for MergetoolToggleLayout (switching between lmr and lm), but not the initial layout from MergetoolStart.

Using gvim started like this (see #17) :

gvim --nofork -c "simalt ~x" -c "let g:mergetool_args_order = 'MBLR'" -c "Merge" "%MERGED%" "%BASE%" "%LOCAL%" "%REMOTE%"

Hi,

Thanks for the amazing tool.

I am a touch confused about how branches are labeled. Here is the following scenario

git checkout my_stuff
git rebase her_stuff
# ... conflict happened
vi readme.md 

I have noticed that if I run git rebase her_stuff instead of git merge her_stuff, the former marks the windows very differently. For example remote window ends up having my stuff whereas local shows her_stuff.

What is the optimal setup in this scenario? Or is this not the right tool for rebase type workflow?