Setup

To achieve this there are a few prerequisites:

• neovim and git are installed
• a merge conflict to test the config against

Next Git’s config has to be updated in one of the following places:

1. $HOME/.gitconfig
2. $XDG_CONFIG_HOME/git/config
3. Inside the git repository under .git/config (for repo specific configuration)

All of these are parsed and concatenated by git before command execution takes place. NOTE: Local configuration overrules global configuration options if present.

To update such files different approaches can be considered.

For instance, using the git cli: git config mergetool nvim

This only registers a variable which still needs a command to be executed.

git config mergetool.nvim.cmd 'nvim -d -c "wincmd l" -c "norm ]c" "$LOCAL" "$MERGED" "$REMOTE"'

A short notice what is actually being executed here:

• nvim -d opens neovim in diffmode.

• -c "wincmd l" executes <C-w>l to move the focus to the next split to the right.

• -c "norm ]c" puts the cursor inside the split to the first change. It is the equivalent of hitting ]c in command mode which is indicated by norm. Command mode is also known as normal mode in vim.

• "$LOCAL" "$MERGED" "$REMOTE" defines the arrangement of the displayed diffs.

After inserting the new options git config -l | grep 'merge' should reveal the following:

merge.tool=nvim
mergetool.nvim.cmd=nvim -d -c "wincmd l" -c "norm ]c" "$LOCAL" "$MERGED" "$REMOTE"

Inside the git config file it should look similar to this:

[merge]
	tool = "nvim"

[mergetool]
	keepBackup = false
	prompt = false

[mergetool "nvim"]
	cmd = "nvim -d -c \"wincmd l\" -c \"norm ]c\" \"$LOCAL\" \"$MERGED\" \"$REMOTE\""

Run

Entering git mergetool will then parse all merge conflicted files and populate them iteratively to the mergetool command.

Resolve

:diffget local will use the left diff from the local changes and :diffget remote vice versa.

To jump to the next change use [c.

After resolving all conflicts for a given file :wqa finishes the process and populates the next merge conflicted file into a new diffview.

Furthermore git will also place backup files of the originals inside the git repository, unless git config contains keepBackup = false. Git will also ask before any merge conflicted file is opened in a diff, unless prompt is set to false.

This is just one approach among many, but it works quite well for me.

Further reading:

1. git manual for even more configuration options.
2. neovim source for more cli examples.

“Success is not final, failure is not fatal: it is the courage to continue that counts.”

I don’t know about you but working on and with software I often find myself in a constant search for information to tackle domain specific problems. Scraping together information from different sources can be tedious sometimes but usually helps me to understand a topic better. But what do I do the next time the same situation occurs?

The point is, it often feels like that I am revisiting sites or posts I’ve already been to for a similar if not the same reason. There is nothing wrong with that in the sense, that if you don’t need it regularly you probably don’t need to remember it by heart. In alignment with that I wish I had shortcuts to the information I once found.

By writing things down I’ve experienced and learned, I get a better sense for my skill. It helps me to reflect on the topic but also on keeping things somewhat organized. Hence the idea of this blog was born and the attempt to aggregate such findings at one place to keep them handy. Furthermore this is also a chance to help others in their search for answers.

Why don’t you just use medium.com or dev.to for that?

I can’t stand paywalls, so medium is a big no-no for me. dev.to is nice and I might integrate cross-posting into my pipeline someday but not now.

So the idea of starting a blog has been on my mind for quite some time. Fortunately I finally managed to spin up a setup that I found simple and functional enough to achieve this.

I really like clojure and I am probably gonna switch to a clojure based solution in the future, but for now I found hugo to be the best quick solution. Hugo is a popular static site generator and you might want to use it too if you are planning on starting a blog. There are a lot of good reasons to use static site generators in favour of a full-fleged web-framework. It’s pretty fast, good on security and you can host it everywhere to name just a few reasons.

This site is hosted on gitlab.com via gitlab pages. The template is still just as is and I did setup gitlabs CI/CD support to test my site on updates. So each time I check in an update to gitlab the updated site runs through some tests and only gets online if these pass.

You could easily use another service for that or even host it yourself, but gitlab pages is a pretty decent option in my opinion.

Furthermore other people are able to read this and maybe learn something through it as well. Even if it’s just a link to a better source to their question.

So if you are interested in programming, coffee or anything else of the things I’ve mentioned in my about section you should come back from time to time. If one of my posts helped you in understanding a topic or getting a setup done, please let me know.

The site also provides an RSS feed you can subscribe to if you like. I’m planning to put at least one post a month online.

It’s a try so let’s see where this is going.

Have a great day.

Ciao, Jan

Update: I’ve switched to a self hosted solution and moved the blog to github.com