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
.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
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…
Tags: techtips git linux
Sign up for My Newsletter!
Get monthly (or thereabouts) notifications on Entropy Arbitrage
posts, additional reading of interest, random thoughts, and previews
of upcoming projects, delivered right to your inbox. I won’t
share your information or use it for anything else.
You can view previous issues.
If you disable trackers (like I do), this form won’t work, so you’ll need to sign up on Mailchimp's site. Sorry!