Just Use Email
How to use Email for Everything

We are abusing Git and wasting time by using it for personal projects and small work projects

Published on

This is not really about email. So if you love email and don't want to read about Git, modern software development, version control, or programming, skip this one.

How is this related to email? In one sense the Just Use Email website is about keeping things simple, but no simpler. I focus on email because, in my opinion, this is where things started to slip away from simple and wonderful electronic communication into a world of brazen thieves, tyrannical middle-men, and privacy-abusing conglomerates - all who wanted to be part of your communication with friends, family, and businesses.

Largely, they have succeeded beyond what they even schemed. The misconceptions about email they have stirred up are repeated by people, and now an entire generation, that have barely even used email to successfully accomplish things with it.

Lots of people believe that only using email as a primary communication tool is all-but impossible. They think they need instant messaging (even though instant messaging is not even instant anymore), workplace messaging tools, CRMs, complex knowledge management, to-do apps and task tools, and worse. Even when email is used (as it must be for many things still), the proper use of email has declined to an almost Neanderthal level.

As part of the transformation of this website away from content management systems like WordPress, and now away from using a static site generator like Hugo, I was not even tempted to use Git to manage my plain old HTML. Or should I say, I was not even tempted to control the versions of my website? Ugh... that sounds annoying just to say that out loud.

I think the Githeads are routinely missing the Bigger Picture - why use Git at all?

Admittedly, I'm not a developer and I don't code full-time. Other than my day job, I mostly do what some would say now is old-school web dev stuff. I've only used Git because I have been forced to interface with developers on work projects.

I know and agree that Git is helpful for massively large code bases used by many developers simultaneously.

Which is exactly the use case that Torvalds created Git for: the Linux kernel codebase. This idea that Git was some "upgrade" from Subversion or prior VCSs is a myth. Torvalds was just scratching his itch. It worked great for him and his remote asynchronous team of open-source devs.

Keep in mind, these are people who still have discussions by email listservs. That's right! They use email to manage changes to the codebase. As discussed in this 2016 article on LWN, "email remains the best way to manage a project as large as the kernel".

Even on smaller code bases with less devs, Git can be very helpful.

Beyond those use cases, however, Git is a lame tool, and a clodgy/clunky one at that. On personal projects or even small work projects with only 2-3 developers, Git is a waste of time.

Here's a few counter-thoughts that we should think about when we think about tools and tech:

1. Bajillions are being spent on self-driving cars, yet Git can't figure out basic intentions of users in dealing with primarily text files. "What? You want to actually commit those files? And with a message? All of them? Are you sure? You'd better type that out explicitly over several commands so I can do that for you. Boy, this is strange territory we're wondering into, partner. You'll probably never want to do this again today, but if you do, be sure to be just as explicit as before. No way I can figure out what you're doing by myself. You must tell me... every... single... time."

2. Apple's "time machine" simply saves an incremental (delta) copy of files, just as git does with commits, and you can picturesquely scan back and forth to find the version you want. For the very few times I've used Time Machine, it works fine. You have time-date stamps of all saves and a larger-than-life thumbnail that you can zip into and out of blazing fast. 99% of git commits would be served by this same type of tech.

3. Office 365 and Google Docs do the same thing, yet less picturesquely, but with incredible ease of use — and most importantly, with multi-user collaboration. Similar to the new VS Code collaboration tools, you can see people editing their changes live. If you need that sort of thing, you can do it without Git.

4. Git was created at a time when the "cloud" didn't exist with any degree of reliability. My early days using SVN were, like many, spent syncing to a central office "server" that had the uptime reliability of a Yugo. And of course, we couldn't "dial in" from home or other places because that was a "security issue", meaning, our small firm had no one who really knew how to lock down Windows Server. In other words, when Git was invented 15 years ago, the "D" in DVCS was a great safeguard to work conflicts and as a robust safeguard against the failure of central repositories, or limited access to them.

5. It doesn't help that the average "I hate Git" article starts by toying with Fossil, SVN, Bazaar, Mercurial, Perforce, etc… I think if Git were the Devil, it would love us to sit around playing that game. Granted, for some companies and use cases, it's a fair question, but for many others, it's like playing with the Lessor of Two Evils, which much to Satan's delights, is still Evil. He still gets his victims to embark upon more unseemly emotional torment as they debate between the Chief Demon or one of its many minions.

Those kinds of things make me think that in 95% of use cases, Git is overkill.

A lot of the Big Sells of Git are not daily use scenarios, but extreme overlord worries: What if six devs need to check out a file at the same time? What if we want to have multiple branches (as if more simple CVSs don't do branching suddenly)? What if we don't have/want/know-how-to-create a central server repository when Github/lab is free?!? What if one of our Devs lives in Alaska and can only connect once a week to the internet when he hikes three hours to the nearest town and plugs into a shared DSL line? What if we need to rebase everything, or merge eleventy branches at once?

What really grates me is this: When you look at a little piece of software on the net, say for instance a static site generator for a blog, the first thing you see in the tutorial is "git init"! There are only two "reasons" people recommend this: 1) so that you can have a complete history of every meddling micro change you've ever done (which in my professional opinion is bordering on paranoia and OCD), and 2) so that you can "clone" various plugins and themes, as if somehow .zip and copy commands stopped working all of a sudden.

Don't even get me started on the obnoxious git submodule command which now ties some part of your little blog codebase to the developer. I have to tie basic HTML and CSS to the original developer via Github? So I can publish an eleven article blog and slowly abandon it over the years? Why anyone would create a dependency on a blog is beyond my comprehension, but never mind me. WordPress is hassle enough. But at least Automattic isn't going anywhere. I highly doubt that your average Hugo theme developer will be around next year.

Young developers who grew up knowing only Git have this idea that it is somehow a trusted backup. They gitify everything.

It's just another glob of files on your hard drive or SSD. Which fail eventually. I just store my /projects directory in iCloud drive or OneDrive and trust that both my computer and these massive companies won't both fail at the same time. If they do, I'll take that as God's signal that my projects probably weren't worth the time I was wasting on them.

Why not just trust the file system and have something similar to Time Machine? If I had a bumper sticker for this, it would be "Commit = Ctrl=S".

Now, I can hear devs scream and rant and rave. "No, no, no… what about tags and branches!? What about Commit Messages!?!?". Listen: 99.9% of the commit messages in the world will never be read after 24 hours ever again. Ever.

For every person screaming about commit messages, there are two more people arguing on blogs about how often to commit and how to type commit messages. Again, on super large code bases, this could be helpful, or critical. But your project is almost guaranteed not to be a contract for NASA, so let's take down the hyperbole a notch.

Devs love to spend time worrying about doomsday scenarios. "I have a friend that didn't use version control and they lost a week of work. They had to try to roll back to some prior code change". Such a scenario doesn't now mean that every LOC (line of code) ever written by any dev on any codebase in any company must now use Git. Simple old-school hourly, daily, weekly, monthly backups in a Cron job would have not cost that company a week of work, but maybe only a few hours (finding and restoring the right backup). But that likely requires (ahem!) central repo management, something the world has crazily abandoned.

This is what "normal" business people (read: non-devs) call "risk management". You don't just buy all the insurance in the world and put a fire extinguisher at every desk. That would be what we "normal" people call "overkill". It would be very expensive.

Git is expensive. There is a real-world cost to using it. People seem to think that because it's free and created by Linus that it has some kind of magical power over codebases. It's just a tool and one that should be used sparingly and wisely.

Everytime a developer has to type "git commit -m 'add footer tag; removed old-school divs'", a robin falls from its nest dead. Just type Ctrl-S and move forward with your day, with your life. Do you really want to go back and look at those old-school divs again? Heck, what if Git had been around since 1995? We'd be able to roll back to all-caps HTML 4.0 pages! Fun, fun!

I suspect that some Git users are the same types that keep the birthday cards they got when they were 9 in a shoe box because, well, you just never know.

Why isn't Git's standard "git" command an automatic commit instead of looking like a help command. That same line above should simply be "git -m 'add footer tag; rem old-school divs'". Git has no reasonable defaults. Any decent use of git requires that each machine be littered with aliases or else you'll be typing "status" all day long like a child. Who's in charge? Us or the Machines?

Granted, that's why people use visual git tools instead of the CLI sometimes, but the whole Git process is clodgy to begin with.

What if we just saved our files locally and relied upon Time Machine, or some as-yet-unknown system that can do so quietly in the background and also allow collaborative editing?

What if we relied upon Azure, Google Cloud, AWS, and the like to host our repos and made them central again?

What if we stopped buying the paranoia stories of Release Management? What if Senior Devs could just lock some files from editing? What if we decided that maybe 25 pushes per day with 9 CI-integrated tools was maybe getting expensive at $45+/hour per dev when all we're doing is managing a Drupal installation?

What if we stopped trying to do every single thing on the web and rolled out software slowly and intentionally again?

I'm quite comfortable using the file system on all personal projects and doing the absolute bare minimum with Git (For work, I routinely annoy devs by only doing one commit per day. Several hundred LOC changes across 23 files in one commit... my reply to them: "I know what I'm doing and I have a life. Go write all those commit messages yourself or hire me a secretary. You'll never even read them." (or learn to use diff).

Why people version-control their own writing is beyond healthy. Are you two people in one? If you make a mistake, if you "lose work", if you suddenly wish your file was just like it used to be eleven versions ago, then you know what? You are a loon! It is a website, not a design for an F-22 Raptor. You are not working with 30 other people on a tight deadline. You are making nothing of value other than the value it has for you and a few random people who care... like almost any artist. And, like any artist will tell you, if you glitch, you work around it and create something new, maybe something better. Or you learn. Don't keep your training wheels on by using Git for small or personal projects.