Not Committing Frequently Enough? Clone To RAM Disks!

What are you nuts? RAM is volatile!

You ever tell someone you're working with to save a document and they go, 'Oh ya, it has autosave... sooo.' Well, git doesn't do that. In fact, git doesn't care about how you choose to use it; it was designed that way by Linus himself for fundamentally good reasons.

Git also doesn't help you with your stale branch problem -- again, for good reasons.

As an FYI, if you haven't experienced this yet, management will freak out if you don't push code at regular intervals -- I reaaaally want to say this is also for good reasons.

So, in order to make the team happy, I've developed a workflow I use to ensure I'm always rebasing, adding, committing and pushing. I make the fear of losing the code a reality. I'd like to share that fear with you now.

Like a good engineer, RAM doesn't hang around long, and neither should your feature branch

RAM actually disappears, unlike most hard drives, statistically

So, if I know that every second is a huge risk for my branch, because it's sitting in a RAM-backed virtual disk and not on a drive, I'll fetch/rebase/ACP it more frequently (FRACP??! - this is not a thing).

WARNING. What could possibly go wrong?

Unlike the potential hard drive crash dilemma, you actually will lose work on a RAM disk. Make sure you actually add/commit/push your work so it doesn't go to bit purgatory.

WARNING. What could possibly go right?

Personally, I like getting a fresh clone when I go back to a repo to work on it after some time has passed. Whatever's deployed now certainly doesn't match that crusty old thing that's been hanging around for three month's worth of time machine backups... with a ton of .gitignore excluded files that nobody else can see. Should I really spend time rebasing all my stale branches? And what about all those freaking node_modules, just sitting there?

Cool story. Let's try it

Try it on Mac

Fire up your terminal.app and type in the script below to mount an ~6 Gigabyte RAM disk called git:

diskutil erasevolume hfs+ git `hdiutil attach -nomount ram://$((6*512*4096))`

Then you can clone something to it and start working. This example clones the amazing Algorithms 4th Edition book source code:

cd /Volumes/git \
&& git clone https://github.com/kevin-wayne/algs4.git \
&& cd algs4 \
&& less README.md

# if you're stuck in the readme, press q to quit

Try it on Windows (using WSL / Ubuntu)

There's a way to do this using PowerShell but I think it's kind of clunky. There's tons of info on this out there, and there's also some paid utilities you can get. But my approach is to use WSL Ubuntu because that's what I'm mostly using on Windows anyway.

My approach is adapted from linuxhint's great tutorial.

# make the mnt directory
sudo mkdir /mnt/git

# mount 6 GB of RAM under the directory
sudo mount -t tmpfs -o rw,size=6G tmpfs /mnt/git

Now you can also clone the awesome Algorithms 4th Edition book source code:

cd /mnt/git \
&& git clone https://github.com/kevin-wayne/algs4.git \
&& cd algs4 \
&& less README.md

# if you're stuck in the readme, press q to quit

In Windows Explorer, you can go to \\wsl$\Ubuntu\mnt\git to access the RAM disk in the GUI.

Mac/PC/Linux, it's easier to stay in one environment

I like Windows and I like OS X. But as an engineer I need to speed up my setup process. So I choose to use the OS X Terminal on OS X, and the WSL Ubuntu on Windows. Most of the terminal navigation is the same. Much better than jumping between PowerShell and z-shell.

Other uses for RAM disks

I do this workflow on the Mac all the time, not just for code things. Especially with filesystem stuff like zip/unzip or Chrome's temp files, which don't need to eat up my SSD lifespan. I'll fire up a RAM disk, get the final state of things I need, move them off the disk (or not), then unmount the drive.

Until next time

I hope this article helps you. It's actually the second one I've ever written. This workflow has helped me over the years and I wanted to share it with you in case you're struggling with finding a productive ACP workflow. Have fun out there, Joe.