I'm a software developer with a huge, insatiable appetite for programming and learning. I love Git, Javascript, PHP, Python and doing some dev-ops.

Ignore changes to specific git files

There are times when you are working on something that should not be committed even though it has changed. In this instance, it’s often not wise to add the changed files to the .gitignore, maybe because the file(s) should always remain in the repo or let’s say suppose it’s a config file with your own private key for an additional service you are using locally, not everyone on the team even uses it. Whatever the case, git has an easy way for this: git update-index! Here is how it works:

git update-index --assume-unchanged [path_to_file]

This simple rule will delist/hide all changed files from future commits. That means you are free to edit them locally and the changes won’t be staged nor pushed upstream! Listing the file(s) is just as straightforward and is enabled by:

git update-index --no-assume-unchanged [path_to_file]

Whilst this command is handy, it does not come with an easy way to untrack an entire folder, which is kind of not-great. However, this can be easily done by a bash command that can list and transverse through the file list, updating each file’s entry in the git index. (Challenge: give yourself a shot and see if you can create this type of command. I’m happy to share my solution to those that attempt and leave a comment, or ping me anyhow! )

Update-index is a command that does exactly what it describes, it tells git to update its index for tracked files. When we set it to assume-unchanged what that does is set a property in the index, for the file to not be checked for any changes. This of course means there are performance gains to this approach with unburdening git from doing unnecessary indexing. However, keep in mind that should the file be changed upstream, when merging commits git will still ignore it locally so it does introduce an extra step to be aware of.

Lastly the commands are pretty long. Easy way I use is to set them to something friendlier by aliasing them in my gitconfig file as follows:

assume-unchanged = update-index --assume-unchanged
assume-changed = update-index --no-assume-unchanged

After this change, you can easily call: git assume-unchanged [file]!

As always thanks for reading, if you have tips or advice or specific other ways you handle this please fire away in the comments below!

i agree with boring

I couldn’t help but nod my head the entire length of the blog post written by Jeremy Wagner on make it boring. It’s not often that I find someone literally following my train of thought so succinctly, albeit from their own unique angle. The principle behind the post is that boring things are the big stones to be put in first.

Learning to learn

When was the last time you thought about how you should be learning? Like many, I realized I went through formal education immersed in different kinds of learning methods but remained oblivious to reasons for using them. This has always bothered me because I enjoy learning, a lot and quickening the speed of it whilst reaping all the benefits, is the ultimate goal. With that motive in mind, I decided to enroll in the free course: Learning to learn by Terrence Sejnowski and Barbara Oakley on Coursera. This blog post will outline some of the insights I have found helpful.


As is custom, at the end or start of year I share my goals and progress as we close and open new chapters. I don’t think there’s an actual chapter closed or opened, it’s comforting to think about it that way but i think life is a continuos stream of … life events that ultimately define our entire existence, there is no break. None. Whatever it may look like, it is a continuation. It’s a mere formality then to state that the last year and all that took place had been a long time coming, whether we acknowledge it or not.

Comparing what my aims were at the end of 2017 and now, I cannot help but feel like I am no longer as open with some of my ideas, goals etc. The reasons behind that are not quite apparent to me, but going through last year’s post I even marvelled at how much I shared about my life and where I intended to go. I sure do hope to investigate my reasons for initially defaulting to scraping the surface with this blog post.

Recent takeaways from pairing

A couple of weeks ago, my workmate paid a visit to Harare from his place in Cape Town for some pair programming, again (yay!). After having had a head start in coding a web app for a mobile application (built with Xamarin), the objective was to quickly knock it into shape and ship it out. I had chosen VueJS for the frontend (because it’s awesome), supported by an API in Laravel - to maintain consistency with the mobile app, we wanted everything to remain exactly the same. During the time of pairing, I learned even more lessons than the other times when I have paired with other programmers.