As part of my renewed dotfiles setup and dev box setup, I’m taking the opportunity to update my core suckless.org tools: st, dwm, dmenu.
I’ve been using these for some time, and it’s great for me to be able to customize tools I use.
In this post, I’ll re-create a new ST fork using up to date code base, and new patches that will work for me.
Note: The focus will be on branching strategy and resolving merge conflicts. The aim is to show an effective way to leverage git and merge tools to integrate patches. You may want to read my previous post describing how merge conflicts can be resolved using tools.
As you may know, git is a distributed version control system that can sync with multiple remotes.
To get started, I usually:
Lets do this:
The resulting remote setup is:
and my current branch setup:
You can see that my local master branch tracks my github’s origin/master branch.
For each patch, I will:
How do we know how to create the branch?
In the case of most patches, the filename indicate some context. In the following example, we will apply the patch st-xresources-20200604-9ba7ecf.diff. From the file name, we understand the patch was created June 4th from the commit hash 9ba7ecf.
Now the trick is to create our branch from that commit. Reading the git documentation, you can learn this is done with the syntax: git branch
Sometimes the commit hash does not match the history, in this case, use git log and find a commit hash close to the patch creation date.
Lets do this and apply the patch:
And we can see what has changed:
and lets confirm it worked:
Everything’s good, now is a good time to commit our changes:
and merge the branch to master:
I will do the same for the following patches: externalpipe and scrollback:
If I build master, I have both scrollback and xresources patches included:
You may get couple of merge conflicts around keybindings, configuration, and similar.
They are usually really simple to solve using a merge tool as described in this previous post.
I had no conflict patching st, but had some when patching dmenu. Here are some examples:
Example of such conflict when merging border and borderoption on dmenu master branch:
In this case, I will select the remote (the borderoption branch) since it makes the attribute mutable.
In this case, we need to take both the local (center patch) and the remote (fuzzymatch patch), so I select C and B to get this result:
I hope I was able to show how simpler patching tools can be when using a branching strategy, branching from the right version, and using tools to resolve conflicts.
Yes you can do all this manually on the same branch, but it’s takes more time and it is much more error prone. Tools are better than us to identify patterns and repeat tasks.
Have fun patching! :)
This is day 10 of my #100DaysToOffload. You can read more about the challenge here: https://100daystooffload.com.