Once in a while, I have a small problem with some regularity that has an easy solution. Traditionally, I write a note to myself, somewhere, and then need to hunt down the note when I need it next time. Since that’s inefficient, whenever I have a few of these, I’m going to start using them as short blog posts.


If anybody else finds them useful, that’s great, but it’s at least as important to me to be able to just look through the https://john.colagioia.net/blog/tags/techtips summary lines for what I want, instead of needing to sift through my notes with hundreds of other random ideas, assuming it made it to my specific note-taking app. And it’s also now a fixed URL that I can point other people to, instead of copying and pasting into e-mails.


We’re all familiar with git, right? If you’re not, I’m going to go out on a limb and say that you’d be well-served getting to know it, even if—especially if, maybe—you’re not a programmer. If there’s interest, I can give an overview of its usefulness outside of software and what such people should know, at some point.

But the short version is that git allows you to keep the history of your projects, so you can look back at earlier versions to grab things you deleted weeks ago or have broken since. Depending on what kinds of files you work with, it also makes it easier to merge changes from multiple contributors or the same contributor from multiple computers. It’s handy. I used it when writing Seeking Refuge, for example, and will accept changes that way, too.

Don’t worry, that’s not the tip. There are a couple of things I’ve needed to do with git that were extremely helpful in context.

Ignore Checked-in Files

The .gitignore file doesn’t apply to anything that has already been checked in. For configuration files and scripts that require customization, this is a problem. For example, my deployment script for this blog needs to refer to my server and my ID, of course, but that’s useless to anybody else, so I don’t want to commit that information. But if you just leave the file around, you need to remember what can and can’t be checked in every time you commit, which is a good way to make mistakes.

Worse, if you search for how to fix this, the Internet has weird obsession with removing files instead of ignoring them, so this works better.

git update-index --assume-unchanged path/to/file

At this point, the file is still part of the repository, but changes to the files will be ignored.

And to undo that change, so that non-custom changes can be committed…

git update-index --no-assume-unchanged path/to/file

So, now the file shows up with any changes. Perfect…except that it’s hard to remember.

Compare Two Branches

Note: This is a bit more software-oriented than the other items. It’s very unlikely that this would be useful to you unless you’re writing software that people buy.

Especially in situations where a company (maybe not-so-smartly) has continued support for multiple versions of a product instead of forcing the customer to upgrade, it’s easy to end up in a situation where the same complicated change (multiple commits fixing an older bug) needs to be merged into several different branches.

But, because of the way git works, merging a branch somewhere other than its parent is generally going to be a disaster. So instead, you need a list of commits that exists in the new branch, but not in the parent. You can then cherry-pick each of those commits to whichever branch needs them.

git cherry -v source name-of-the-development-branch

You need to be on the parent branch for this to work, otherwise, you’ll get bad results.

Show Changes for Part of a File

The log provided by git is usually fine for following history, but for high-traffic files, we’re probably more interested in the history of just a function/method. For that, we want to get the log of the lines of the file that include the target. If our function runs from lines 120 to 135, we have…

git log -L 120,135:path/to/file

This filters the log to only show the changes where the specified lines (which are followed correctly as they move around) have been modified, making it easier to find out who made a particular change to ask for background. Of course, every time I’ve done this, the person to ask was me, but that just means I can speak more harshly about the change…

Linux - Fix Inaccessible Hard Drives

In my end-of-2019 retrospective, I mentioned that I was having trouble accessing an external hard drive from Ubuntu. Changing USB ports didn’t work, nor have any recent software updates. A reader, guessing that the drive was kept formatted as NTFS and wishing to remain anonymous, recommended the following command:

sudo ntfsfix /dev/whichever-drive-is-the-problem

The drive in question is probably named starting with sd.

If there are corrupted files on the drive, this won’t fix them in the same way that CHKDSK /F would on Windows, but it does fix whatever was blocking me from mounting it and I don’t see any bad files, so I’m calling it a win. Thanks, anonymous person!

With any luck, someone will heroically explain what went wrong with my DVD codecs, too…

Credits: The header image is work, technology, vintage, wheel, retro, clock, by an anonymous PxHere photographer, is made available under the terms of the CC0 1.0 Universal Public Domain Dedication.