Superfud

"Oh no, I hit a timeout" -> "I've increased the timeout and added a retry" -> "Oh no."

Batteries fortunately do not destroy the raw materials they are made from. So eventually we can stop mining new raw materials once we have built enough batteries. In addition, batteries for cars live a surprising long time - and can be used to stabilize the grid once they diminish in oomf (technical term).

ddrescue can read from /dev/urandom and write to any device. This can come in handy when you have a device with bad blocks but still would like to "shred" all the still writable parts of.

A change ID is stable over time as you tweak the message of the change or the files edited by the change. Each of these changes become a new immutable git commit under the hood.

The fact that change ID is stable is very convenient for humans - means you have something explicit to hold on to as everything else may change over time.

Initial empty commit with just a message you can create with "git commit --allow-empty -m'Early commit message"

Then when you have the changes lined up you --amend that same commit.

This is probably the very first thing you tried, but maybe don't cut the nail quite so short? Recommend upgrading to sharp and precise nail cutters as they make it easier to control exact nail length.

For PostgreSQL, the manual is extremely well written, and is warmly recommended reading. That should give you a robust foundation.

Hitting enter two times gets you out of code blocks. It's the only consistent method I have found.

Readwise allows you to “recover” your streak if you miss a day for whatever reason. I’m sure it is for the exact reason you cite here.

Sounds like a simple solution which gets the job done. Using whiskey_disk would reduce your typing by a bit (repeatability is nice for things done all the time), but if you don't have any post-commit tasks you have to run on each deploy, stick with what you have.

Where you'd really see benefit would be when you have multiple config files (with database credentials and addresses, for instance) that vary per server and environment involved. In addition, if you need to run post-deploy actions such as building assets, or run database migrations, a tool would help you.

However, until you feel the pain of your current setup, no need to change what works :)

Good question! The main benefit is you deploy directly from your git-server to your production server, instead of uploading from your own computer. This means a lot faster deploys, especially when your deployments are large or your internet connection is really poor (being able to make deployments quickly while on a 3G connection is awesome). whiskey_disk uses one ssh connection to your server for all work (so less time for spawning ssh connections), and the heavy traffic is not to/from your local machine.

Other benefits of the tool include putting all config files into version control, and a lot less less magic in your deployments.