GitLab’s Default Branch Name

GitLab is now implementing a change to make the default branch “main” instead of “master”, following GitHub and Atlassian in ditching the “master/slave” namings due to their negative history.

It should be noted that this change this makes little difference to the functionality these sites provide, and to git repositories in general. Also, the default branch can be overridden.

When creating a blank initial repo in GitLab or GitHub (i.e. without a README.md file), the sites will prompt you to push code in using instructions such as this (GitLab haven’t yet implemented the master –> main change yet so it still shows master on their instructions)

git clone git@gitlab.com:username/example.git
cd example
touch README.md
git add README.md
git commit -m "add README"
git push -u origin master

But there’s nothing to stop you from doing something like

git push -u origin trunk

Instead of master at the time of pushing.

trunk is also one of the three folders used in Subversion Version Control as part of the recommended layout (trunk, tags, branches) — yes, I did use svn previously, along with Mercurial, Visual SourceSafe, and even cvs.

trunk is also a more logical sounding main branch as you have branches that lead into the trunk of a repo. And the leaves could be considered to be the tags.

While it is great that the big name hosting platforms are migrating away from the master branch idea, it should be noted that you didn’t have to have this default branch name originally, nor were you (or are you still) tied to using their choice of main branch name.

Microsoft to Acquire GitHub

Sad news that M$ are to acquire GitHub. I suspect I’ll start getting Windows adverts in my email inbox soon as my office uses GitHub

On the plus side, this LinuxJournal article has proposed some alternatives. GitLab is a good one and even mentioned on some job listings so I guess I’ll move my repos there.

I’ll be removing my GitHub repos…

https://www.linuxjournal.com/content/microsoft-reportedly-acquire-github

Google Music

A while ago, I posted of my frustration with Google Music when it refused to download my tracks. Well, I did some digging around and found that someone had written an API to expose the Google Music backend. The link is at

https://github.com/simon-weber/Unofficial-Google-Music-API

and has spawned several other tools including

https://github.com/thebigmunch/gmusicapi-scripts/

Which is a set of scripts designed to sync, upload and/or download from the Google Music collection.

I wrote my own Python script using the Gmusic API to bulk delete albums from my Gmusic account (it’s easy to bulk upload using Google’s MusicManager, but not to bulk delete), and the gmusicapi-scripts enables me to download most of my tracks.

git Snippet: Proxy Configuration

I do a fair amount of work using git as version control, with SVN and CVS close behind, but I haven’t used any of them so much as a distributed version control.  However, since I’ve started using Bitbucket and GitHub, I have encountered many issues to do with DVC. One of the main ones is communication via proxy.

My workplace doesn’t allow communication through the net without it going through a proxy server and it is an major pain in the arse to get through. Fortunately, git allows you to configure git to use a proxy server:

To use a proxy server for HTTP communication:

git config --global http.proxy http://user:password@proxyserver:9999

To use a proxy server for HTTPS communication:

git config --global https.proxy http://user:password@proxyserver:9999

My company firewall also injects its own SSL certificate, which breaks SSL verification, so to get around that:

git config --global http.sslVerify false
%d bloggers like this: