DEV Community: Hugo Dahl

Some Helpful Git Commands

Hugo Dahl — Sat, 06 Feb 2021 20:19:56 +0000

(Re)naming Things is Hard!

What's the deal?

Working through a few things while following along with @foamyguy from the Adafruit community, who was streaming some pull request reviews on YouTube, a few git "gotchas" were mentioned. A few of these have to do with the order of operations, others are a personal preference, so I thought I'd share the various configurations and commands used, and to help me remember when I next need it.

git clone, origin, upstream fork you up

Depending on your personal workflow when working with a repository that isn't yours, you might or might not run into this issue. In this case, @foamyguy (and me, and others I know) run into this issue where we clone the original repository, hack away and do some work, commit and try to push our changes, only to realize, we're trying to push to a repository where we don't have access... or worse, where we DO have access (like the principal one), and mess things up for everyone. In this case, if we want to name our default remote something other than "origin", there are a few options...

Set the remote name when you clone it
git clone myownremote https://github.com/.....
This will name the remote "myownremote" instead of "origin"
Rename the remote after you clone it when you remember.
git remote rename origin montypython
This will rename the remote called "origin" for the current repository to "montypython".
Set the default remote name in git's configuration. WUT???
git config --global --clone.defaultRemoteName source
That's right, if you're not fond of the default name "origin", you can choose a default name that you prefer. So if you prefer to name your default remote "source", you can tell git to name it so by default.
Bonus Round - GitHub Edition!
If you use GitHub as your main repository, you can use their recently released command line tool, "gh". If you use their "repo" functionality with the "fork" verb, it will automatically perform the following tasks for you
1. Create your own fork of the repository on GitHub
2. Clone the repository to your local system
3. Setup your fork on GitHub as "origin"
4. Setup the original source as "upstream" To do this for a project owned by the account called "projectowner" with the repository name "super-project", the command is this simple... gh repo fork projectowner/super-project

Edit to add: I just happened to clone another repository using the GitHub CLI, using the gh repo clone (since I didn't need a fork), and since it's ultimately using git for any of git operations, if set your configuration as in step #3, your default remote name configuration will be applied.

Branches have names too, you know!

Branches behave in a similar manner to remotes, but the syntax to change them is significantly different. But it's worth knowing how to name or rename them to how you want them.

Renaming an existing branch
git branch -m old-and-busted bugfix/This-shall-not-fail
In this case, we're calling the "move" (-m) command for branch "old-and-busted" and changing it to "bugfix/This-shall-not-fail". A way to help remember is that this follows the pattern to rename items in Unix and Linux based systems.
Giving it a name at checkout
git checkout -b feature/I-name-things-good
This will checkout a new branch called "I-name-things-good", based either on the current branch and commit (HEAD) where you are now or based on a branch in the remote with the same name if there is one based on the checkout.defaultRemote configuration value.
Greet it a nickname
git checkout -b ralph feature/I-name-things-good
What this will do is nearly a duplicate of option #2 above, with the exception that you're a) explicitly specifying a source branch, and b) explicitly naming your branch something different. In this case, we're checking out the branch identified as "feature/I-name-things-good" on the remote to our local repository with the name "ralph".

The End/Fin/Closing Credits/Final Curtain

So those are the two major renaming activities that are done in git. Sure, there are others, but in my experience, the need to use them is so rare, I don't actually remember quite when the last time happened to be!

CircuitPython 2021

Hugo Dahl — Mon, 04 Jan 2021 02:37:53 +0000

Where Do I Think CircuitPython Should Focus for 2021

What IS a CircuitPython Anyway?

No, it's not some sort of snake or reptile. Nor is it some sort of SteamPunked techno-jazzed Ourobouros. CircuitPython is an adaptation of the Python programming language with a focus on MicroControllers. These can be used for all sorts of purposes, such as monitoring air quality, making blinky lights, operating garage doors, automatically feeding pets, etc. Pretty much anything to which you would say "It would be nice to have a gadget that ...", you're likely thinking about something that uses a MicroController.

Why Do I Care About CircuitPython Anyway?

This past year, particularly the last 5-6 months, I've started REALLY getting into the hardware side of technology. I've had a more than mild interest in it for quite some time, but things never seemed to line up for me to really do more than just dip the proverbial toe in.

This past year, like for so many other people out there, hobbies and mental distractions, such as reading, really helped keep things in some form of perspective. And so, I started investing more of my time in reading, learning, and really forging ahead with my hardware interest.

I've been following the work, projects and community of an incredible hardware company, Adafruit, for quite some time. What makes them incredible? Glad you asked, I made a list, albeit incomplete:

They are an open-source hardware company
They support the community in so many ways
Their code of ethics is well laid out (see their editorial standards to get a good idea)
Their focus on education and enriching lives is HUGE, and at the core of their principles

While I could go on, and elaborate on many of those items and many more, that's not what's on my mind today. Today, they shared a blog post regarding where their programming language, CircuitPython should focus for this year. Being such a community focussed organization, they're seeking, like they do every year, input from the community of CircuitPython users.

Ok, Genius. What Are Your "Great" Ideas?

Since I've really been neck-deep in it lately, I had a few ideas which I thought I would contribute, in case others out there also thought of, or raise pain points which others have either accepted or found alternate workarounds for.

As such, here are some of the things I've had ideas about doing:

Managing libraries, and their dependencies
Localization(ability?) of the platform
"Build" tool

Ok. Tell Me More...

#1 - Library Management

One of the biggest pain points I've run into, and that I've noticed other users have as well, is making sure that all the required libraries for a given project, as well as their dependencies, are included and copied to the microcontroller. Having a tool that can manage the libraries and dependencies would make ensuring that nothing gets missed when testing the project on actual hardware.

Another benefit is that the base image for each board could be made much smaller so that only the libraries necessary are installed. For example, if you're using a board that has audio capabilities, but don't intend to have any audio as part of your project, that library can be left out. The benefits of this would likely be minimal since the CircuitPython language and framework exist in a different section of storage on the board - at least, that's my understanding of it. However, it might allow for simpler builds of CircuitPython across various boards based on the same platform.

#2 - Localizationability..ness of the platform

Another addition that might be nice for the platform and its wider adoption, is having the libraries be set up in a manner that would allow them to be localizable. The core framework and language are already localizable, and there are already many translations underway.

However, with the various libraries for the huge assortment of peripherals and sensors from both Adafruit and others in the community or developed by 3rd parties, most aren't localized, and there isn't a pattern or technique defined for localization. Part of the issue might also be that there's no way, at least that I've seen, to know which locale (language) is deployed to the board. Perhaps someplace helpful to put that, if not as part of the global memory space, would be to read it from the boot_out.txt file, as I've seen done for information regarding the version of CircuitPython installed on the board.

Being able to select either a .mpy file to copy to the board or better yet, a specific file-per-language which can be copied to the board, next to the .mpy file. Something like a .cpl for [C]ircuit[P]ython [L]ocale, or whatever would be determined to suit the community.

#3 A "Build" & Deploy Utility

note: This one turned out going on much longer than the previous two, and I detailed maybe a bit too much. Maybe it's a sign of putting too much functionality into it. So maybe it's a "suite"? Either way, it's a jumping-off point.

The final thought I had, which also quite nicely ties into the first to, is a type of packaging and deployment tool so that development can be done locally on a system that is separate from the microcontroller device, without the need to be connected to said device.

This tool could incorporate a few helpful features related to developing detached from the device. Features such as trimming excessive storage use within the code, by (optionally) stripping comments, reducing extra and simplifying whitespace (replace x spaces with a single tab, spaces within parenthesis), and other options similar to modification in Javascript.

This would also provide a uniform manner in which a linter could be used, with default "best practices" rules. These would be applied to the development code, that is, the code on the computer, and not the code pushed to the microcontroller.

Additionally, given that using print() statements for debugging is such a standard technique, it could allow stripping those calls from the code. Alternatively, it could lead to adding one or more similar methods, such as log(), debug(), warn() and the likes, or possibly a separate module. That module, or the calls to the debugging methods, could optionally be stripped out of the "release" code, so that the print() calls remain. Or to keep it more in line with the root Python language, making use of python decorators for debugging output? It would avoid the need to add and remove these debugging statements (if leaving them in but commented out takes too much storage space) after the problem has been isolated and rectified.

So this utility, combined with the functionality I described above in #1, would ensure that only the libraries necessary for the project, given the target board, would be copied. And when combined with what I've described with localization in #2, would ensure that the correct resources/files are deployed for the specified locale.

It could also, in the longer term, be used for updating the version of CircuitPython on the target board with ease for newer users, who are either unsure of themselves and their abilities or have a harder time getting the devices in boot-loader mode.

The final benefit of such a tool is to allow for the full copy of all files to the target device, without triggering a soft-reboot mid-copy. There are issues with editors who do not write files in a single block to CircuitPython devices, causing them to reboot mid-copy. There are also external utilities, such as operating system services/daemons, backup utilities, antivirus scanners, malware detectors, and their likes, which have caused issues rebooting boards unexpectedly due to a misguided "write".

Having a way such as this utility, that prevents the untimely occurrence of a soft-reboot, could be beneficial. In essence, a polite utility, which will hold the metaphorical door open for someone moving something heavy into a building.

Are We There Yet?

So there you have it, things that I believe would be of value to the CircuitPython ecosystem and community, that could be explored and developed for 2021, and quite possibly expanded upon for a few years thereafter. So how far off into left-field am I with these ideas? Am I in the same ballpark? Am I even playing the same sport??? I guess I'll find out!

I'm also extremely curious to hear what others in the community, especially the core developers and maintainers of the ecosystem, have as far as plans and proposals for the year. Regardless of what those are, I for one, ~~welcome our new steam-punked snake overlords~~ look forward to helping out in any meaningful way that I can!