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.

After tolerating the instability of ZR3 for a long time, I have finally decided to quit using the app. It has become unusable, crashing EVERY use at least once and causing other apps to force close as Android tries to frantically free up memory for the black hole that is ZR3. Six to Start have not even addressed this issue, even though they acknowledge it is a memory hog.

The resources I have made – the Google Music tutorial page, and the Bitbucket respository, will remain up for now, but will not be updated further. If someone wants to pick them up and continue with them, by all means, do so, and let me know, so I can add a redirect or link to your site.

Grive is an open source command-line-based sync tool to synchronise a directory with your Google Drive. Grive is not in the Fedora repositories, although it is undergoing review for addition into the repositories.

In the meantime, if you want to use it, I’ve written a script that should pick the latest version from the russianfedora website. Bitbucket repository is here.

Direct link to script: here

Once you install the application, create a blank folder (this will be the sync folder), then run grive -a to request an authentication URL. Go to that URL, log into Google if you need to, and you’ll get a response string you need to copy back into the console window. If the authentication was successful, Grive will sync your files into the folder. Each subsequent time you run Grive, it will download and/or upload files to/from your Google Drive.

There is only one limitation that I’m aware of. Documents created from within Google Drive won’t sync, but if you convert them to odt or doc files, they will sync.

Looks like it wasn’t just me that was having trouble with the BB service.

Report on Sunday’s Outage

They mention a webcrawler caused the problem. I wonder which one it was? ¬_¬

Up until know, I’ve been following tutorials on modelling in Blender and they all use box modelling. However, I wonder if I could take a modular approach instead, and model parts of the character separately, then merge them together. The only reference images I have (short of drawing my own) are three-quarter views, which are a lot harder to model from a face or side view. So, if I model say the leg and foot independently, I can clone it and attach it to the torso.

Going to branch my Bitbucket repo and give this a go.

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 [proxyserver](http://user:password@proxyserver:9999)

To use a proxy server for HTTPS communication:

git config --global https.proxy [proxyserver](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