2020-02-02 Encrypted Org-mode journal

I use the Org-mode capturing feature to write a daily journal, where I record various important events in the case I’m going to need the information about them. Some time ago it occured to me that encrypting that journal could be a good idea, so I decided to explore that possibility.

Now Emacs has this nice feature that if you save a file with the gpg extension, it gets automatically encrypted (during the first save, Emacs will ask you for the keys to use, and if you select none, for a passphrase). It turns out that combining the Org-mode capture templates with handling gpg files turns out to be trivial: it is enough to tell Emacs that the journal file ends with .gpg, like this:

(setq org-capture-templates
 '(("j" "Journal entry" entry
    (file+olp+datetree "~/")
    "* %i%?\n"
    :time-prompt t
    :unnarrowed t)))

(I personally like :unnarrowed for journaling, but YMMV) – and that’s it.

CategoryEnglish, CategoryBlog, CategoryEmacs

Comments on this page

2020-01-27 Splitting a past commit in two, and a bonus regex trick

More than a year ago I described a very simple Git rebase workflow, where all we were interested in was just fixing some mistakes in a past commit. Let us now go a little bit deeper. One thing I had always trouble with was splitting a commit in two (or more). While there are many tutorials about this on the internet, I wrote my own, even though it turned out that it is not better than the other ones. Go figure. (One advantage is that I have it on my website, so that I won’t need to do much searching in case I need it.)

(Of course, if we mean the last commit, we don’t really need fancy rebase – we can just git reset HEAD^, stage some things, make the first commit, and then proceed to the second one (or more). The tricky part is editing earlier commits.)

Let us begin almost like previously.

cd /tmp
rm -rf rebase-edit-tutorial	# in case you run this again
git init rebase-edit-tutorial
cd rebase-edit-tutorial
echo 'Initial commit' > file.txt
git add file.txt
git commit -m 'Zeroth commit'

echo -e 'This commit\nwill be split in two.' >> file.txt
git add file.txt
git commit -m 'First commit to split'

echo -e 'This commit will stay.' >> file.txt
git add file.txt
git commit -m 'Another commit'

We now want the two lines of the First commit to split to be added in two subsequent commits. Here’s how we can do it. Start with git rebase -i HEAD^^. Change the pick in the first line to edit, save and exit the editor, and then say git reset HEAD^. (Note that this is a different HEAD this time! To see what exactly HEAD is every time, say e.g. git rev-parse HEAD.) Here’s the explanation: rebasing puts us (more or less) in a state “right after HEAD^^=”. Since we want to change =HEAD^^, we need to go back just a bit further, to the moment before we committed it. This is what git reset --mixed HEAD^ does – and by the way, --mixed is the default, so we can omit it. (Actually, this takes us back even further, to the point before git add, i.e., not only does it reset the HEAD, but also the staging area.)

We can now add and commit the first line we introduced in our commit. Say git add -p and then e. Delete the second line beginning with + and exit the editor. Say git commit -m "First part". Now you can just git add file.txt and git commit -m "Second part". Finish off with git rebase --continue and you’re done.

One thing that is not mentioned in many tutorials is that this way, you completely lose the commit message of the commit you have just split in two (or more) parts. If that is a problem, there is a -c option to the git-commit command, which accepts a commit hash and uses the commit message from that commit as the basis for the new message. (There is also a variant, -C, which does not let you edit the message – it just takes another one and applies it.) Of course, the commit is not visible in the log now, but it is not gone from the repository – you can look it up in git reflog, or git rebase --abort, make a note of the commit’s hash and repeat the rebase.

But whenever you use a computer and feel the need to “make a note of something” manually to reuse it later, it is a sign that either you are doing something wrong, or the author of the tool you are using did something wrong. Now guess who is smarter, you or Git developers? (Well, that was mean, sorry.) Here is a trick: you can say git rev-parse :/'First commit to split', or even just git rev-parse :/First. What is this? Well, whenever Git wants you to give a commit hash, you can use the :/regex syntax, which gives you the newest commit reachable from any ref (like HEAD or branches) whose commit message matches regex. How cool is that!? The :/ syntax can do even more – say man gitrevisions to learn about it and other ways to specify revisions. You may thank me later. ;-)

CategoryEnglish, CategoryBlog, CategoryGit

Comments on this page

2020-01-19 tldr

For today, I only have a short tip. Some time ago, I discovered this little gem called tldr. This project aims at creating an example-based alternative to man pages. It comprises several hundred short pages containing a short, one-line introduction to the command explained and a bunch of examples.

Of course, man pages are still indispensable. But if you have ever been in a situation when you just wanted to e.g. run GNU find to look for some files but exclude one directory, you know that looking for that in the man page is a PITA. Well, saying just tldr find gives you exactly what you need as one of the examples. Many other utilities are covered, included, but not limited to coreutils. There are pages for many Git commands, the Silver Searcher and its successor ripgrep, HTTPie, tar, screen and tmux, Node.JS, a little utility called x_x I’ve never heard of earlier, youtube-dl, psql and many, many others. You can even say tldr vim or tldr emacs, and, as expected, learn how to quit both! ;-) (You can also download a huge pdf with all the pages, or install various clients, including several CLI ones and an Emacs one.)

Go to the website of the tldr tool to learn more (also about similar projects!).

CategoryEnglish, CategoryBlog

Comments on this page