In contrast to the simple single-line nicely-behaved “git submodule add” command, removing a submodule requires you to: $ git submodule deinit -- path/to/submodule $ rm -rf .git/modules/path/to/submodule $ git rm -f path/to/submodule $ git commit -a -m "Remove submodule" Apart from the multiple steps with “rm -rf freely being tossed around willy-nilly, note the second command where you manually fiddle with the guts of the repository structure. That does not get propagated up to any remotes in a push or any repos that pull from you or a shared remote.
TL;DR: Just look at the Gist. Summary: Act I, in which I try and fail. Act II, in which I think I succeed but actually failed without knowing it till I tried to use it. Act III, in which I return to my beginning, ponder the universe, dive deep into the depths of the abyss, and come back with the magic bean that makes everything work.
For the sake of future me, I am recording this here, the coolest shell trick I’ve learned this year: (Linux): tar cf - /folder-with-big-files -P | pv -s $(du -sb /folder-with-big-files | awk '') | gzip > big-files.tar.gz (OSX): tar cf - /folder-with-big-files -P | pv -s $(($(du -sk /folder-with-big-files | awk '') * 1024)) | gzip > big-files.tar.gz with output looking like: 4.69GB 0:04:50 [16.3MB/s] [==========================> ] 78% ETA 0:01:21 Requires ‘pv’: https://github.
R doing what R does really, really, really, really, really, really, *R*eally well: visualization. Folks, this might be THE plot to use to visualize distributions of discrete/categorical variables or simultaneous distributions of multiple continuous variables, replacing or at least taking up a seat alongside the violin plots as the current best approach IMHO. Source code repository: ggjoy Example of use (EDIT: This plot style is named after the “Joy Division”, due to a similar graphic on one of their album covers.
Biblatex is a fantastic bibliography/citation manager for LaTeX. It trumps the older bibtex for its much easier customizability and configuration. It does however, have one bug that can be very perplexing to figure out due to the misleading error message that results: “Could not find all biber source files”. At first glance this message seemed straightforward enough to send me poking about the project file structure and build system, checking paths and names.
With every iteration of their desktop operating system, Apple seems more and more determined to try new and novel ways to irritate me. The rootless security model that prevents anyone from writing to ‘/usr‘ (except for ‘/usr/local’; though there is no way for you to re-create this directory if you wipe it). The big problem is that the build process of GCC requires that ‘/usr/include’ exists, and the OSX 10.11 security model does not allow you to create it.
Insert mode is not the mode for editing text. It is a mode for editing text, because both normal and insert modes are modes for editing text. Insert mode, however, is the mode for inserting new/raw text directly from the keyboard (as opposed to, e.g., from a register or a file). Thus, you will only be in insert mode when you are actually typing in inserting (raw) text directly. For almost every other editing operation, normal mode is where you will be.
We all know about no-op’ing arrow keys in Vim to get us to break the habit of relying on them for inefficient movement. But, as this post points out, it is not the location of the arrow keys that makes them inefficient, but the modality of the movement: single steps in insert mode is a horrible way to move around when normal mode provides so much better functionality.
A queen of color schemes …