I needed to merge some changes from a development file into the file on the real website, and discovered that the program I most often use for that, meld, is in one of its all too frequent periods where its developers break it in ways that make it unusable for a few months. (Some of this is related to GTK, which is a whole separate rant.)
That led me to explore some other diff/merge alternatives. I've used tkdiff quite a bit for viewing diffs, but when I tried to use it to merge one file into another I found its merge just too hard to use. Likewise for emacs: it's a wonderful editor but I never did figure out how to get ediff to show diffs reliably, let alone merge from one file to another.
But vimdiff looked a lot easier and had a lot more documentation available, and actually works pretty well.
I normally run vim in an xterm window, but for a diff/merge tool, I
want a very wide window which will show the diffs side by side.
So I used gvimdiff instead of regular vimdiff:
gvimdiff docs.dev/filename docs.production/filename
Configuring gvimdiff to see diffs
gvimdiff initially pops up a tiny little window, and it ignores Xdefaults. Of course you can resize it, but who wants to do that every time? You can control the initial size by setting the lines and columns variables in .vimrc. About 180 columns by 60 lines worked pretty well for my fonts on my monitor, showing two 80-column files side by side. But clearly I don't want to set that in .vimrc so that it runs every time I run vim; I only want that super-wide size when I'm running a side-by-side diff.
You can control that by checking the &diff variable in .vimrc:
if &diff set lines=58 set columns=180 endif
If you do decide to resize the window, you'll notice that the separator between the two files doesn't stay in the center: it gives you lots of space for the right file and hardly any for the left. Inside that same &diff clause, this somewhat arcane incantation tells vim to keep the separator centered:
autocmd VimResized * exec "normal \<C-w>="
I also found that the colors, in the vim scheme I was using, made it
impossible to see highlighted text. You can go in and edit the color
scheme and make your own, of course, but an easy way quick fix is to set
all highlighting to one color, like yellow, inside the
highlight DiffAdd cterm=bold gui=none guibg=Yellow highlight DiffDelete cterm=bold gui=none guibg=Yellow highlight DiffChange cterm=bold gui=none guibg=Yellow highlight DiffText cterm=bold gui=none guibg=Yellow
Okay, once you can view the differences between the two files, how do you merge from one to the other? Most online sources are quite vague on that, but it's actually fairly easy:
|]c||jumps to the next difference|
|[c||jumps to the previous difference|
|dp||makes them both look like the left side (apparently stands for diff put|
|do||makes them both look like the right side (apparently stands for diff obtain|
The only difficult part is that it's not really undoable. u (the normal vim undo keystroke) works inconsistently after dp: the focus is generally in the left window, so u applies to that window, while dp modified the right window and the undo doesn't apply there. If you put this in your .vimrc
nmap du :wincmd w<cr>:normal u<cr>:wincmd w<cr>then you can use du to undo changes in the right window, while u still undoes in the left window. So you still have to keep track of which direction your changes are going.
Worse, neither undo nor this du command restores the highlighting showing there's a difference between the two files. So, really, undoing should be reserved for emergencies; if you try to rely on it much you'll end up being unsure what has and hasn't changed.
In the end, vimdiff probably works best for straightforward diffs,
and it's probably best get in the habit of always merging
from right to left, using do. In other words, run
vimdiff file-to-merge-to file-to-merge-from,
and think about each change before doing it to make it less
likely that you'll need to undo.
And hope that whatever silly transient bug in meld drove you to use vimdiff gets fixed quickly.
[ 20:10 Jun 09, 2016 More linux/editors | permalink to this entry | comments ]