Git

A piece of software never exists in isolation and without context. The problem to solve and the reasoning and experience of its programmers shape the implementation and are important information for future developers. Even well-written code cannot convey all of this by itself. Therefore, further means of communicating such information are required. Code comments and external documentation are the obvious choices. However, with Git we also have the chance to design the commit log in a way that it deliberately tells a story about the implementation that is not visible from the code itself. Table of contentsWhy code and change sets need to communicateRecording history vs. telling a storyProperties of good commitsCreate cohesive commitsExplain what has been done and WHYCreating a clean commit historyBibliography Why code and change sets need to communicateProgramming is a form of human communication, mostly with other humans; incidentally also with the computer by instructing it to execute a function for us. Therefore, when implementing something we carefully need to consider how to communicate what and how things are done, similar to when we talk to each other about a manual task using natural language. We need to negotiate why and how we do things to ensure that everyone understand what to do and in which way. Otherwise, misinterpretation, confusion, and conflicts are pre-programmed. With current software development techniques such as pull/merge requests, the phrase that code is read much more often than it is written or changed is probably even more valid than it ever used to be. Reading only makes fun and delivers the required insights if the literature you are reading is well written and not a convoluted mess of illogical mysteries. Similarly, reviewing a pull request only works well if the proposed changes are presented in a way that is understandable. Clean and self-documenting code is an important technique to ensure a reasonable reading experience. However, the code itself mostly explains what and how something is realized. The really important pieces of information usually hide behind "why" questions. Why did I use this design over the more obvious one? Why this algorithm and not the other one? Why is this special case needed to fulfill our business requirements? Why do we need to make this change at all? These are actually the important pieces of information that will likely cause confusion sooner or later if omitted. Bugs might be introduced in future refactorings if business requirements and their special cases are not known to someone reworking the code. New features might break the intended design if it wasn’t clearly presented. Finally, a pull request review is much more productive and also more pleasing for the reviewer if requirements, design choices, and motivations are known. Code comments can answer many of these issues if done properly and much has been written about how to create useful comments (e.g. [Atwood2006], [McConnell2004] chapter 32, [Ousterhout2018]). Good and concise recommendations are: Comments augment the code by providing information at a different level of detail. Some comments provide information at a lower, more detailed, level than the code; these comments add precision by clarifying the exact meaning of the code. Other comments provide information at a higher, more abstract, level than the code; these comments offer intuition, such as the reasoning behind the code, or a simpler and more abstract way of thinking about the code. — [Ousterhout2018]...

I am constantly using several different computers (home, work, servers) and synchronizing the configurations of the shell and all other command line utilities I am using across these computers can be a bit challenging. Manually copying everything including all changes constantly appearing in the different configuration files is the worst solution. So I have been using a repository on my self-hosted Seafile server with all the required dotfiles and a custom setup script to create the required symlinks to these files. This worked quite well but also had several drawbacks. Therefore, I recently switched to homeshick to manage my dotfiles and, during this process, published most of my dotfiles on GitHub. ...

I am using password managers since a long time to maintain secure and individual password for different online services. One thing that always bothered me was the missing integration of these password managers with different applications. I started my journey with password managers using KeePassX but recently switched to pass (the standard unix password manager) due to the inherent command line nature and therefore much better integration and remote usage possibilities. Still, there was no easy way to integrate pass with Git (for those repositories where SSH key authentication is not possible) and until recently I still used kwallet as the backend for Git, with all the hassles of duplicated data. To improve on this situation I finally took some time and implemented an adapter between Git and pass: pass-git-helper. ...

In order to apply only changes for a selected file from the git stash you can use the following command line (bash): git diff stash@\{0\}^1 stash@\{0\} -- path/to/your/file | git apply Based on the Stackoverflow question: How would I extract a single file (or changes to a file) from a git stash?

As I am working on a lot of different computer I wanted to share some of my configuration files across these computers to have similar working environments on all of the machines. An easy solution to do this is e.g. for git to put the .gitconfig file (along with other configuration files) into a folder inside the Dropbox (or other syncing tool), create a symlink to that file in the original location in your home directory and let Dropbox do the syncing. ...