Automated updates: 2020-01-29
This commit is contained in:
John Colagioia
parent
b6311a9dce
commit
1254b3d9ce
2 changed files with 86 additions and 1 deletions
|
|
@ -3,7 +3,7 @@ layout: post
|
|||
title: Metal Umlauts, Searching, and Other Unicode Fun
|
||||
date: 2019-12-17 17:01:12-0500
|
||||
categories: programming
|
||||
tags: [javascript, unicode, programming, technology]
|
||||
tags: [javascript, unicode, programming, technology, techtips]
|
||||
summary: Re-normalizing strings for improved user experience and entertainment
|
||||
thumbnail: /blog/assets/writing-book-vintage-antique-texture-old-629962-pxhere.com.jpg
|
||||
---
|
||||
|
|
|
|||
85
2020-01-29-tips.md
Normal file
85
2020-01-29-tips.md
Normal file
|
|
@ -0,0 +1,85 @@
|
|||
---
|
||||
layout: post
|
||||
title: Small Technology Notes
|
||||
date: 2020-01-29 06:48:55-0500
|
||||
categories:
|
||||
tags: [techtips, git, linux]
|
||||
summary: Ignoring changes, comparing branches, local histories, and external drives
|
||||
thumbnail: /blog/assets/work-technology-vintage-wheel-retro-clock-606288-pxhere.com.jpg
|
||||
---
|
||||
|
||||
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.
|
||||
|
||||
## Git
|
||||
|
||||
We're all familiar with [git](https://git-scm.com/), 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]({% post_url 2019-12-14-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](https://github.com/jcolag/entropy-arbitrage-code) 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.
|
||||
|
||||
```sh
|
||||
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...
|
||||
|
||||
```sh
|
||||
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.
|
||||
|
||||
```sh
|
||||
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...
|
||||
|
||||
```sh
|
||||
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]({% post_url 2019-12-29-review-2019 %}), 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:
|
||||
|
||||
```sh
|
||||
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](https://pxhere.com/en/photo/606288), by an anonymous PxHere photographer, is made available under the terms of the [CC0 1.0 Universal Public Domain Dedication](https://creativecommons.org/publicdomain/zero/1.0/).
|
||||
Loading…
Reference in a new issue