git

Tue, 31 Jan 2023 23:00:00 +0000

Once upon a time, in digital electronics design, we were used to moving huge zip files around including project data, code and all ancillary stuff along with it. We were doing backups, snapshots and versioning our code with help of compressed files. That’s the way it was, I knew that time, and you, young reader, would not believe me if I told you about the whole picture. This is not acceptable anymore.
Today we have (well, we already did 20 years ago, but, you know, we were electronic engineers, not coding experts after all) tools to handle the situation. We have control version, we have git, and this more than we need to follow changes in our code (and our documentation, bibliography, etc.). Sure, we need a bit of discipline to use it in meaningful way, writing clear commit messages, committing correctly, creating clean histories, using the right branching model and learning how to use #git in a collaborative way. Following best practices is something that, as for today, should be accessible to any engineer, provided he is using the right tools.
The point here is how to interface git. In my experience, most hardware engineers (but not only) just do basic clone, push and pull, creating linear histories. Simply put, they use git as a backup system, with huge unrelated commits. They use git because they must use git, as anyone else is doing, but without any of the associated benefits. No history read, no diffs, no topic branches, no rebasing, no merging, no nothing. The reason is they’re using the command line interface (#cli) to git. Using git in the command line is fine, provided you’re fluent with clis, with a good shell and its plugins, and you have a very good long term memory. No one remembers how to interactively rebase 10 last commits on top of another branch, squashing history. Full stop. And no one will commit every 30 seconds if it takes one minute. Forget about. This brings to the clone/pull/push/that’s it step slope most people is faced to when they use git. And, unfortunately, this is the end of using git proper.
Now, what to do about ? #modernhw requires using a GUI to manipulate your git repositories. This will provide you with a lot of benefits, among them, a clear overview of where you are in your git history, your current status, and most importantly, where you’re going from this point. Which GUI to use ? Don’t expect an answer from me. The one you feel more comfortable with is the right choice. No matter what, provided it is #freesoftware. Spend as many time as you need mastering its usage, you’ll be rewarded afterward.
Personally, as I’m using #emacs, my not that original choice goes to using #magit. Magit is a front end application to the command line git, closely embedded within the rest of my workflow. As usual, once one gets used to its way of doing things, it’s really fast to perform any git operation in a few seconds. Within a few keystrokes, it is possible to get the status, log, remotes, branches and doing the difference between to different versions. It gives access to complete much more sophisticated manipulations in less time that it takes to tell about. Try to achieve the same using the command line (you will, but it will take ages). The key here is the time it takes: if you need longer to git than what it takes to think about, you’re using git the wrong way. You’ve been advised.

emacs

Tue, 31 Jan 2023 23:00:00 +0000

#modernhw, and in particular digital electronics design implies, for the most of it, writing #plaintext files. Creating code, scripts, configurations, documentation, emails, taking notes, handling bibliographic references, etc., all of these tasks involve writing in plain text files. Whether these files are created or modified, editing plain text is a must. An, when it comes to editing text, it is really worth investing some time on learning a bit more than the basics of a good text editor.
At that point, once one decides to opt for a good tool, it takes the best of them all. In my case, I decided to start a long journey towards mastering emacs, even if GNU #emacs is much more than a text editor: it is a full customizable environment, and is #freesoftware. Emacs has been around longer than me, and benefits from the accumulated experience of all those having used it well before I discovered its existence. Inside of it one will have access to a plethora of existing applications, make use of killer tools as #magit and #orgroam, handle email with #mu4e, browse the web with #eww, manipulate windows with #exwm, run terminals, compile, develop non-existing utilities, modify emacs’s default behavior, change options, default bindings, etc. It is closer to a customizable working environmetn (a full OS some claim !) that you’ll take the time to build, than just a text editor.
Orgmode deserves a special chapter in here: #orgmode brings plain text editing to next level of productivity. Check the quickstart if you’re not familiar with it. Don’t feel overwhelmed by the its large list of features: links, tables, markup, attachments, agenda, tags, export, publishing ... the list is endless. If you ever feel like tempted to use it, proceed step by step. As with emacs, just pick some appealing feature you think you’ need, and start making use of it. The more you practice, the more you’ll feel more comfortable with it.
You’ll manage, with time and some experience, to build a working environment suited to your particular and special needs, to a point you never imagined it was possible. And most important: you’ll be able to make it evolve with your own needs. It takes time, a lot of it, and the learning curve is quite step, so this is probably not the best choice for everyone. However, once you really learn how to use it (and get used to forget about your mouse !), the benefits in productivity are really impressive. You’ll never look backwards.
If you ever opt to follow the same path as I did, start by the tutorial, and read the documentation. Then, just use it, little by little, no hurries. You’ll be learning something new about emacs everyday during the next 20 years anyway.

magit — csantosb

git

emacs