version control

How To Use Git to Manage your User Configuration Files

There is probably a gadzillion different ways that you can manage and synchronize you configuration files (aka dotfiles) between different Linux/UNIX boxes – anything from custom symlink scripts, all the way to configuration management tools like Puppet and Ansible. Here are a few options to look at if you are not doing it already.

Personally, I’m using Ansible and I’m quite happy with it, as it allows me to have multiple playbooks (base configuration, desktop configuration, development setup, etc), and do more things than just manage my configuration files (install packages and tools that I often need, setup correct permissions, and more).

Recently, I came across this tutorial from Digital Ocean on how to manage your configuration files with git. Again, there are a few options discussed in there, as even with git, there’s more than one way to do it (TMTOWTDI).

The one that I’ve heard about a long time ago, but completely forgot, and which I think is quite elegant is the approach of separating the working directory from the git repository:

Now, we do things a bit differently. We will start by specifying a different working directory using the core.worktree git configuration option:
git config core.worktree "../../"
What this does is establish the working directory relative to the path of the .git directory. The first ../refers to the ~/configs directory, and the second one points us one step beyond that to our home directory.

Basically, we’ve told git “keep the repository here, but the files you are managing are two levels above the repo”.

I guess, if you stick purely to git, you can offload some of the additional processing, such as permission changes and package installation, into one of the git hooks. Something like post-checkout or post-merge.

GitHub pricing : Business

GitHub has yet another update to their pricing options. Business plans have been launched with support for SAML single sign-on, 99.95% uptime SLA, 24×5 support with 8 hour response, and more.

Unfortunately it still counts external contributors as users in the account, which makes it too expensive for my organizations, but it’s good to see them trying.

Moving files with commit history from one git repository to another

I’ve searched for this before, and I’m sure I’ll do that again (although the need is not that frequent), so here it goes. It is possible to move files from one git repository to another, preserving commit history. The following links provide a few examples of how to do this:

Greg Bayer’s explanation
StackOverflow discussion
Another StackOverflow discussion

Basically, you need git filter-branch command, usually with the –subdirectory-filter parameter.

An example of where it is useful would be the extraction of some code from a project you have into a shared library or a simple plugin.

Use vimdiff as git mergetool

Ruslan Osipov has a very handy tutorial on how to setup Vim text editor as git merge tool, for resolving git conflicts.

Basically, run the following commands to tell git to use Vim as a merge tool (don’t forget the –global flag if you want it for all your projects, not just the current one):

git config merge.tool vimdiff
git config merge.conflictstyle diff3
git config mergetool.prompt false

With that, running “git mergetool” after a conflict was reported, will result in something like this:

The three way split window will show local version (–ours) on the left, the remote version (–theirs) on the right, and the base version with the conflict in the middle. You can then get changes from one window into another using the following Vim diffget commands:

:diffg RE  " get from REMOTE
:diffg BA  " get from BASE
:diffg LO  " get from LOCAL

Awesomeness!

Check a few of Ruslan’s other vim-related articles.

GitLab horror story : backup / restore failure

As I am reading this story – GitLab.com melts down after wrong directory deleted, backups fail and these details – every single hair I have, moves … I don’t (and didn’t) have any data on GitLab, so I haven’t lost anything. But as somebody who worked as a system administrator (and backup administrator) for years, I can imagine the physical and psychological state of the team all too well.

Sure, things could have been done better. But it’s easier said than done. Modern technology is very complex. And it changes fast. And businesses want to move fast too. And the proper resources (time, money, people) are not always allocated for mission critical tasks. One thing is for sure, the responsibility lies on a whole bunch of people for a whole bunch of decisions. But the hardest job is right now upon the tech people to bring back whatever they can. There’s no sleep. Probably no food. No fun. And a tremendous pressure all around.

I wish the guys and gals at GitLab a super good luck. Hopefully they will find a snapshot to restore from and this whole thing will calm down and sort itself out. Stay strong!

And I guess I’ll be doing test restores all night today, making sure that all my things are covered…

Update: you can now read the full post-mortem as well.