Giving in to git

Thursday, 22nd August 2019

I gave up on using Dropbox for synchronising my Tiny BASIC project. It works really well for keeping files synced between my Intel-based Linux machines, so I can sit down at my laptop or desktop and have the latest edits available. But it's not very smooth on my Android device. Files need syncing one-by-one for offline editing, and I've found that even then it sometimes doesn't let me edit "offline" files when there's no network available. And it doesn't work on ARM-based Linuxes yet, which means that can't keep the files synced on my Raspberry Pi fileserver.

So I decided to set up a github repository. It's not a syncing tool. But if I create branches for each distinct line of work of the project, and commit and push work in progress to them at the end of each session at a given computer, I can resume that work by pulling those remote branches down to whichever device I'm wanting to use at the moment.

Once a particular job is done, committed and pushed, like say finalising the manual, then its remote branch can be merged into the master branch. To this end I have a branch for the manual, a branch for my work on parsing expressions, and I envisage future branches for parsing the various statements, execution, code generation and whatever else is involved.

In my day job, git is used to allow several developers to work in parallel on the same systems. I've had a number of arguments with git, sometimes having my repos ending up in such a mess that my only way out is to create a fresh clone of the remote repo and copy in my changes from the broken repo.

For this reason I'd promised myself never to let git get near my own projects. But my way of working with git is different, and I have more intimate knowledge of the state of my source files and the repo in general, so repo-killing mistakes are much less likely. And the stakes in my hobby projects are much lower, so I'm willing to give git a chance.