We made the Glamorous Toolkit repositories rely on main instead of the master branch.

This effort was not quite trivial as it involved changing not just one repository, but 54. That was already daunting, but that was not the difficult part. More tricky was that we also had to change the the descriptions of projects and their dependencies (called baselines).

Why change the baselines? Let's take a look at an example. A dependency in a baseline might specify the dependent repository like spec repository: 'github://feenkcom/repo/src'. When no branch is specified in the url, master is default. Instead, we wanted that dependency to look like spec repository: 'github://feenkcom/repo:main/src' instead.

So, we automated this work. Interestingly, we ended up using exactly the same infrastructure that we use when we release our code. When we release, we merge from the main to the release branches and have all baselines point to a reproducible version. In our case, we merged from master to main and changed the baselines.

The release infrastructure also comes with interesting previews of the actions to be performed. This came in quite handy here, too. For example, here is the map of dependencies with all the changes for each repository.

And, of course, we can also see the actual list of changes and accompanying diffs.

We wanted to do this change since quite some time, but we found it a little too daunting. However, once we approached it through a tool dedicated to the job, the problem changed. Indeed, automating the active part of the transformation reduced the overall effort considerably. But, it was the visual overview that what brought with it confidence, and even a little excitement.

There are no boring problems in software development.