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 not wise to add the changed files to .gitignore:

• maybe because the file(s) should always remain in the repo
• or suppose it’s a config file with your private key for a 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 changes on that file in future commits. That means you are free to edit the file locally and the changes won’t be staged nor pushed upstream! Listing the file again is straightforward:

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

Whilst the commands are handy, they do not come with an easy way to untrack an entire folder, which is not-great. However, this can be easily done by a bash command that can list all files you want to “untrack” locally and transverse that list, updating each file’s entry in the git index.

Update-index is a command that does exactly what it describes, it tells git to update its index for the tracked file it is given. When we set that entry of the file in the index to assume-unchanged what that does is tell Git to simply ignore anything that happens to that file. This results in performance gains via unburdening Git from doing unnecessary indexing on files we no longer care about. 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. An easy way I use to set them to something friendlier is by aliasing them in my gitconfig file as follows:

[alias]
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 thank you for reading, if you have tips or advice or 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.

2018

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.