…is that it is hard to articulate what exactly is frustrating about it.
Well, at least for me, at least. I’m not good at articulating my frustrations. But I am, however, rather good at being frustrated. Not an ideal combination to possess. Why must I have been thusly wired?
Anyway. Recently I revisited this classic Tomas Vykruta article about Git. As you might imagine, the reason I stumbled upon the article is that I was searching for some iteration of “I hate Git” or “why Git sucks” on Google in order to get some validation.
Like the author of that article, I also worked at Google. I got accustomed to their development workflow. It worked. It was okay. On some days I even felt productive! Basically, version control at Google follows the traditional model. You have some files. The version control system (VCS) keeps track of versions for each file. You make check-ins. Each check-in modifies some files. You can ask the system, “get me the version of this file made at this check-in.” Everyone could freely borrow code from each other, yet they could also work in self-contained spaces so that they didn’t interfere with each other.
Sure, my experience may be biased. At Amazon, Microsoft, and Google, I and other developers used the traditional kind of VCS, similar to what I was describing above. Perforce, Subversion, TFS, CVS, those are some well-known systems out there for public use.
But post-Google, I used Git almost exclusively, for work and for other projects. Most people outside of the big corporates use Git or something built on top of it, such as GitHub and GitLab. And this worked pretty well. Sometimes, I even felt productive. As far as I could tell, everything was fine.
Until it wasn’t.
Now, I’m not about to go into detail — not good at articulating my frustrations, remember? But it was pretty frustrating, I can assure you. Resolving merge conflicts. Getting into a detached head state (would rather do this with substances, thanks). Having to rebase and go through your own work all over again. Being “N commits behind the target branch.” The ever-present spectre of Git blithely undoing your work if you didn’t back it up enough.
Yes, you can mitigate all that by having standardized workflows in your team. Git is powerful and can do many things, so ideally your team would have a playbook about how your team ought to use Git. Everything should be fine as long as you follow the playbook, right?
…right? Yet, I was seeing the same problems come up again and again, even when there were standards in place. For instance, GitLab is a standard. It’s built on top of Git. And you still suffer the same problems as if you just used the Git command line. In fact, GitLab often tells you to go to the command line to fix issues! What’s the point of having something built on top of Git? And why do we have to write an entire playbook on something that should supposedly just work?
Now of course one can just get better at using Git. As they say… git gud.
git: 'gud' is not a git command. See 'git --help'.
Hah.
Git die-hards would tell you that anyone can and should become a guru at using Git. But why go through all the trouble? Say you drive a car to work. If you had the choice of driving automatic or stick shift, why learn stick shift when an automatic vehicle gets you to work all the same? Asking us to simply get better at using Git is like throwing more time and money at a problem to make it go away. Hint: it won’t go away.
Yes, people might accuse me of being lazy. But laziness underlies a desire for change and innovation, a yearning for what could be possible beyond what currently exists. It’s an inextricable part of engineer DNA. Next they’ll probably accuse me of being human, too.
Perhaps the difficulty of articulating this frustration also applies to technology in general. Technology is supposed to “just work” and make life easier. And sure, it can make life easier — that is, when you don’t use it, life becomes harder. Thus we use technology because we need to, not because we want to.
On the other hand, when you have technology that is pleasing and even fun to use, then it’s a nice cherry on top. Maybe all the world needs is more fun.