When working with Git I sometimes end up with a lot of untracked local files that I want to get rid of. For example, compiling things and testing around can create more stuff than expected or a git reset origin/master rolling back a lot of commits can leave a bunch of leftovers. To me this happens a few times a year and each time I realize that I forgot how I solved it last time. The answer is: git clean . git clean -n Dry-run, show what would be deleted git clean -f Really delete it git clean -d Recurse into untracked directories For me this usually means git clean -f -d and I am done. For more options check out the man page .
In written text there are (at least) three different types of dashes: the hypen -, the en dash – and the em dash —. They almost look the same and often the hyphen is wrongly used instead of the en or em dash because it is the easiest to type with the - key on the keyboard. But the hypen is only meant to be used to connect two words, e.g. home-office, or to split words on a line break. The en dash is used to define a range (e.g. timespan or distance) between two things, e.g. 3–4 meters or June–August. And then there is the em dash, it is mostly used to put additional parts in the middle or at the end of a sentence, a bit similar to parentheses. The use of an em dash is a stylistic element…
I have been running a personal GitLab instance for many years now. Today GitLab 13 with many great improvements and new features was released. While the update process of GitLab is normally so stable that I had no issues with enabled auto-updates for years, this time it failed. But of course it wasn't even GitLabs fault... they deprecated a few config options in 12.3 and I missed that change for straight eight months 🤦♂️. I am using the GitLab Omnibus package to maintain my instance, so to check out the update issue I tried to manually update GitLab: The error message was pretty clear: I was still using some gitlab_monitor options which have been replaced by gitlab_exporter since…
Just recently I started to migrate my blog from Hugo to Gatsby . Gatsby is also a static site generator but it is a lot more flexible than others. While a generator like Hugo only provides a way to build a static site based on markdown files, Gatsby is more like a framework to build whatever you want. In exchange the learning curve of Gatsby is a bit steeper, but they make up for it with excellent documentation . After the first version of my new blog was ready I started to look for a way to build a Docker image for it. During my search I found the gatsby-docker project at GitHub, but it doesn't seem to be maintained so well. When I tried the instructions from the Readme I realized…
In some situations it can happen that a pod or a full node is not available anymore but Kubernetes thinks it is still there. For example, I had a case where a worker node was deleted via the cloud provider API (not via Kubernetes) and Kubernetes did not properly notice this interruption. Then I tried to normally delete the pods of the node but Kubernetes kept waiting for the kubelet to confirm the deletion --- which never happened because the kubelet did not exist anymore. Obviously this kind of situation should never happen in the first place, but for some reason it did. And whether it happens due to a bug or due to some obscure scenario where this is the expected behavior... it will…