Changed diff3 view from 2.36 → 2.67 for vimdiff

Hi all,

when solving a merge conflict using Git and Vim as mergetool, I get a totally different view than I expected and am used to. In the past, I followed this blog post (https://www.rosipov.com/blog/use-vimdiff-as-git-mergetool/), where the result is a view with four windows: LOCAL | BASE | REMOTE and then the file below. Now I get four windows as well, but LOCAL at the top and then LOCAL | LOCAL | file.

First I was not able to figure out if the problem lies within Git or Vim. I removed my global .gitconfig as well as the .vimrc but neither helped. What finally helped was to disguise the HOME directory for Git via this command:

$ git merge octodog $ HOME= git mergetool

My git version:

$ git --version git version 2.37.1

Then I tried older Git versions, 2.37.0 showed the same behavior but Git 2.36.1 showed the old view.

Minimal working example (for bash):

$ cd $(mktemp -d) $ git init $ # ––– config mergetool $ git config merge.tool vimdiff $ git config merge.conflictstyle diff3 $ git config mergetool.prompt false $ # ––– create merge conflict $ echo -e 'cat\ndog\noctopus\noctocat' > animals.txt $ git add animals.txt $ git commit -am 'Initial commit' $ git checkout -b octodog $ sed -i 's/octopus/octodog/' animals.txt $ git commit -am "Replace octopus with an octodog" $ git checkout master $ sed -i 's/octopus/octoman/' animals.txt $ git commit -am "Replace octopus with an octoman" $ # ––– trigger behavior $ git merge octodog $ git mergetool

How can I get the old view back? Is this a bug or a feature of Git? Should I write the Vim guys?

This behavior is independent of directory as well as host, it occurs on a different machine as well.

Thanks in advance, Claudio

Hi Claudio,

On Fri, 22 Jul 2022 at 10:40, Claudio Ebel <claudio.ebel@web.de> wrote:

I'm not a vimdiff expert by any means, but having three windows containing LOCAL seems like a bug to me... For what it's worth, I can't reproduce -- everything looks good to me.

There was some work on vimdiff in the v2.37.0 cycle -- I'm cc-ing the author of those patches. (He also wrote about the work at [1].)

There exists at least one vimdiff bugfix [2] in git.git's current 'master' branch that is not yet in any released version. If you are able to build Git from source, you could try that version to see if it fixes your problem. As far as I understand, that patch relates to end-user vim settings, and you did write that you nuked your .vimrc, so maybe that patch doesn't quite match your problem, although from the original report [3], it does seem similar.

Since redirecting HOME works, I wonder if you do have some other config file after all. Do you have a ~/.config/git/config file? Maybe, similarly, you have more than just one vimrc?

There's also a patch to handle whitespace in paths [4], but it's not yet in git.git's master branch (it's only in the 'next' branch so far). From your description, it doesn't quite sound like the failure mode that patch author described, though. If you're interested in trying it out, you could either `git am` the patch in [4], or you could try `git merge ccc7b5148` into, e.g., current master.

[1] https://u92.eu/blog/git-vimdiff/ [2] https://lore.kernel.org/git/20220708181024.45839-1-greenfoo@u92.eu/ [3] https://lore.kernel.org/git/CACRpdvnuAYY0U1_3uD8zKgtq05+bgwjzXpZKomro6gqYDNrjGg@mail.gmail.com/ [4] https://lore.kernel.org/git/pull.1287.v2.git.1657809063728.gitgitgadget@gmail.com/

Martin

Hi Claudio.

As Martin just said, this looks *very* similar to the behaviour you would experience if you had vim configured to open splits "in reverse" (when compared to the default settings).

You can make this test to confirm whether this is the case or not: try to run this command:

    vim -c "echo | split | vertical split | 1b | wincmd l | vertical split | 2b | wincmd l | 3b | wincmd j | 4b | tabdo windo diffthis" -c "tabfirst" local.txt base.txt remote.txt merged.txt

(note: this is the same command git 2.37 uses when running `git mergetool -t vimdiff`)

It should open 4 windows with the following layout:

    -------------------------------
    |  local  |  base  |  remote  |
    -------------------------------
    |           merged            |
    -------------------------------

If you see something different, please then try to run this other command :

    vim -c "echo | leftabove split | leftabove vertical split | 1b | wincmd l | leftabove vertical split | 2b | wincmd l | 3b | wincmd j | 4b | tabdo windo diffthis" -c "tabfirst" local.txt base.txt remote.txt merged.txt

(note: this is the same command git will run in a *future* version)

Notice that this new command is exactly the same as the previous one but including keyword `leftabove` before all `split` and `vertical split` commands.

If you run this command and this time it displays the expected layout, you have two options:

    A) Wait for the next git version where this will be fixed :)
       (as Martin pointed out, the patch can be found in [1])

    B) Update your .vimrc to include these two lines:

         set nosplitbelow
         set nosplitright

       ...or, alternatively, update your .vimrc *not* to have these two lines
       (as both options are disabled by default):

         set splitbelow
         set splitright

This is also what I suspect.

You can make this experiment to confirm this theory:

  1. Run "vim" and then ":set splitbelow?"

  2. Run "HOME= vim" and then ":set splitbelow?"

If the returned string is different ("splitbelow" in one case and "nosplitbelow" in the other one) it means you have a ".vimrc" (or something else) somewhere in your $HOME that is changing vim's default settings.

By the way, you can list all scripts "sourced" by a vim instance by running this command from inside vim:

    :scriptnames

That will help you find the "rogue" script inside your $HOME. Note that it could happen that some of the other vim scripts you have sets those variables without you noticing!... in that case you can also change their value back *at the end* of your "~/.vimrc"

Fernando.

[1] https://lore.kernel.org/git/20220708181024.45839-1-greenfoo@u92.eu/

Dear Martin, dear Fernando,

first of all: Thank you both very much for your super fast and elaborate answers. It's amazing to get responses from the developers themselves! I read the blog post about the new vimdiff layout with delight. I like the new feature very much, especially the decision and implementation of the generic mechanism which is indeed better than the introduction of new vimdiff4, … layouts. I think I'll stick to the “advanced” four tab option for my future merge conflicts, like you suggested in your blog, too.

Regarding the problem, yes, you both were right, I have had a “second rogue” vimrc in my home directory. It has been – as most often – a “layer eight” problem (myself). I have had a ~/.vim directory with a ~/.vim/vimrc file inside. Since I had expected Vim to need an ~/.vimrc file, I had created a symbolic link ~/.vimrc -> ~/.vim/vimrc. “Nuking“ my vimrc had meant for me to delete this symbolic link (~/.vimrc), but as I learned today, the ~/.vim/vimrc file is perfectly fine. You always learn new things! So to really nuke the vimrc, I had to move the .vim directory as well and then git behaved like expected, just like you suggested.

I investigated further and – oh wonder! – I found those two lines in my vimrc:

set splitbelow set splitright

Uncommenting them brought the good old back behavior back, too. So the problem is solved, great!!!

By the way, the buggy layout looked exactly like Matthew Klein reported in Martins link [1]. The difference is, obviously, the difference in tools (his --tool=nvimdiff versus mine --tool=vimdiff).

    ------------------------------------------
    |                                        |
    |                LOCAL                   |
    |                                        |
    ------------------------------------------
    |             |           |              |
    |   LOCAL     |   LOCAL   |   MERGED     |
    |             |           |              |
    ------------------------------------------

I also managed to compile the newest master branch of git (the Arch User Repository git-git package should be fixed, it's broken at the moment, but I managed to bypass all obstacles) and, as you hinted, this version (git version 2.37.1.223.g6a475b71f8) is not sensitive to the "splitbelow / splitright" options!

After successfully compiling Git, I'm almost ashamed to ask, but I was NOT able to run the vim command you suggested, Fernando:

vim -c "echo | split | vertical split | 1b | wincmd l | vertical split | 2b | wincmd l | 3b | wincmd j | 4b | tabdo windo diffthis" -c "tabfirst" local.txt base.txt remote.txt merged.txt

because there are no such files?! What do I have to do before executing this command? I read the man page and tried it with "git config mergetool.keepTemporaries true" and "git config mergetool.keepBackup true", but still no such files appear. I am sure I am missing something completely obvious. Even my google-foo failed… Since I solved my problem on many levels (thanks to your great help), executing those vim commands is not important anymore, I just would like to understand…

Thank you very much again,

with best regards, Claudio

[1] https://lore.kernel.org/git/CACRpdvnuAYY0U1_3uD8zKgtq05+bgwjzXpZKomro6gqYDNrjGg@mail.gmail.com/

Hi Claudio,

Notice that this command was meant to be executed *directly* from the terminal (and not from .gitconfig).

It just opens 4 files that, as you noted, do not exist... but that's ok with vim: it will open 4 buffers named after the provided filenames and only save them to disk when running ":w".

The result should be something like what is shown in [1], ie. 4 empty buffers named "local", "base", "remote" and "merged" shown with the expected layout.

Hope this helps!

Fernando.

[1] https://postimg.cc/dL8G2mng