MacOS

A Guide to using git pull --rebase effectively Using git pull --rebase as your default merge strategy offers several benefits, particularly in maintaining a clean and linear commit history, which can simplify collaboration and code review. However, users may occasionally encounter the error “Cannot rebase onto multiple branches”. This article explains why this happens and provides a solution to make git pull --rebase work seamlessly. Benefits of git pull --rebase Linear History: Rebasing applies your local commits on top of the upstream changes, creating a straight line of commits without unnecessary merge commits....

I was a big fan of the Atom1 code editor, so when it was discontinued and replaced by M$’s VS Code2, I was both sad and dissapointed. While I can admit that VS Code is a solid editor, my personal preference always leaned towards Atom. However, over time, Atom started to feel sluggish. I collected numerous plugins over the years and it began to weigh heavily on performance, not just during startup but also during regular usage....

I rely heavily on shell usage. For over 15 years, I was a devoted user of Bash until I discovered Zsh and made the switch. One thing that remained constant throughout my transition was my configuration to maintain an extensive commands history. This setup is replicated across all my systems. When you spend a lot of time coding, you often find yourself repeating commands or running variations of them. Remembering all these commands can be challenging, but with resources like Google and ChatGPT, it’s not always necessary....

First contact with make When I was invited for my first job interview in the IT, I’ve been asked such question: How would you typically build a program from sources, what commands will you use? I answered: It’s obvious: ./configure make make install Those times belong to the past now and nowadays not many programmers use GNU Make1. Try asking this question and you will see disgust at best. For many it’s the fist contact with make and often the last one, but not for me 😉...

Working with Docker environments amid diverse architectures, like Apple’s arm64 and x86-64/AMD64, presents challenges. I’ve encountered the clash between my Mac’s M1 arm64 architecture and my x86-centric server workloads. The solution? Just use DOCKER_DEFAULT_PLATFORM 1 2. Just run in the terminal: Enforce platform for all commands export DOCKER_DEFAULT_PLATFORM=linux/amd64 With this command, Docker enforces x86 architecture by default on commands supporting --platform parameter, streamlining workflows and sparing the need for repetitive --platform specifications....

I love blogging with Hugo  external link and I have two blogs already that use it. The good thing about static sites is that you have all the data in the files. You can optimize them locally, batch process, amend, etc. Powerful templating engine allows to quickly pre fill documents in the format I like. I have some steps in the Makefile for things like image optimization, but I often don’t remember to run them 😃...

I use Git a lot, even writing this article i will commit text few times. There’s a set of aliases I rely on daily and they’re first I add in new place. Some Git commands are unnecessarily verbose. You can make your life much easier with bash-completions, but if you write it tens of times per day, it’s anyway a lot of typing… and I’m a lazy man 😄 Simple status/log checks git s s = status --short --branch --untracked-files Shows a short, branch-focused status with untracked files....

I switched recently from Docker Desktop  external link on my MacBook to Rancher Desktop  external link . The most important reason for me to do it, was possibility to gently switch between docker and containerd runtimes. There’s still one feature that I miss on Rancher Desktop - possibility to change Docker daemon configuration. I used to enable experimental features1 and BuildKit2. Sadly, there’s no easy way to do it on Rancher… But there’s a magical way3....

I don’t know how it is in your company, but in mine it’s considered a good practice to add ticket numbers to commit messages. It allows to easily determine why something was changed, etc. Makes sense, but this also means, that I should be adding this ticket to every message… And this doesn’t make sense for me. I will accidentally avoid it from time to time or make a lot of typos....

I was updating my blog and needed to generate few variants of images, in different resolution. Option 1 - sips There’s simple, builtin tool sips, that can be used for simple resizing 1: Resize single image sips -Z 36 orig.png --out static/favicon36x36.png -Z - maintain image aspect ratio 36 - maximum height and width It can be also used for batch image processing: Warning Beware, without –out param, it will overwrite images in place!...