Mislav Marohnić changelog.com/posts

Git is simply too hard

whatever comes next should be closer to how humans think

This is a fancified excerpt of Mislav Marohnić’s unpopular opinion on Go Time #153. Mislav works at GitHub on their new Go-powered CLI. To get the full experience you should listen while you read.

🎧  Click here to listen along while you read. It's better!   🎧


Git is actually sooo hard. Not just to learn, but also to use consistently.

And I say that as a person who used it for probably over ten years. I’ve used it since GitHub was in beta, and I heard of this Git thing, and it was trending, and it was cool, and probably my only early adoption thing kicked in around that time, when I wanted to check it out…

Since then I’ve been using it probably every day. And I have interfaced with it so often. I’ve read all of its man pages, and documentation, everything. And still to this day (ten years later) sometimes it’s hard for me to explain.

When people come to me with a very basic question of like:

Oh, I just pushed a change. I really didn’t wanna push that, so how do I undo it?

So from their perspective, that’s a really reasonable question to make. And then I’m just like:

I’m sorry… This is gonna sound like I am teasing you or that I’m mocking you, but actually I’m really being frank, and I’m gonna give you my advice. It’s just not gonna be great.

Or for instance, when people ask:

How do I delete a branch?

and then I have to ask them:

Well, what do you want to do? Do you wanna delete a local branch, and then just get it recreated when you pull again from the same remote? Or delete the remote tracking branch? Or delete the remote branch?

And now for the first time I’m realizing that they have never even considered that there’s such a thing, because why would they? A branch is just a single concept in our head that is made complicated by the inherent distributed nature of Git.

The tech

It’s not to say that I’ve become disillusioned with the tech itself. I think it’s amazing, and I think that the tech itself is… the quality of the tech that is Git is a testament to GitHub being able to make it this far in the tech space. And I think it evolved amazingly as well.

But I think in its evolution it’s only getting bigger. It’s just getting more commands. And even though its documentation is getting more approachable to newcomers every year… and there’s really good man page documentation now… and error messaging is fantastic because it often suggests what you should do next to get yourself out of the mess that you’ve accidentally made…

I feel that with all that power that it’s gaining, instead of being a more approachable tool, that it’s actually being a tool that is continuously making people feel frustrated, to the point where I feel that whatever the next version control system is…

(And it does not have to be something separate than Git. It should maybe be just a really powerful abstraction built on top of Git.)

But I think whatever the next iteration of the people’s version control is… it should be something that is more reflective of how we think about what version control is for us.

How people think about things is generally always very simple:

I have some changes. I wanna share it with Jon and Johnny so they can tell me what they think. And then maybe they can add their ideas. And then we can have a merging of our ideas, and eventually test out if it works, and have it out there and ship it.

That wasn’t hard to explain. I think it’s very easy for all of our listeners to understand that mental model in their heads. But then when we come to physically typing out all those commands… suddenly we need months or sometimes even years of learning this set of tools to become proficient enough with them.

What about GUIs

I have really initially resisted the idea of graphical tools for Git, because I was this heavy terminal nerd; I was very much in my terminal bubble of being really proficient with a lot of these things, because I was for ten years (before even my Git learning) using just terminal tools in general, because I was a very Linux nerd. And I feel that even though it was possible for me to learn that, I feel that nobody should need to have spent so much time in a terminal to be able to understand those things.

I especially see it when somebody not from my background is approaching this.

So I would definitely say it’s not such an unpopular opinion. I’ve heard a lot of people express their anguish (especially on Twitter) with their inability to use the Git command line even after a long while.

The user hands-on aspect of version control –how we interact with it– needs to be built in something that is much more closer to how humans think about it. Rather than being:

I will get you to think about a directed graph or as operations on a directed graph

No human thinks about that! Humans think about:

I’m gonna save my work and I’m gonna share it with other people. Then I’m gonna step off this computer and just leave for the day.

In other words

I guess this short TL;DR version would be I feel that version control systems (the next version of them) should not be something that was specifically made for the Linux Kernel community. It should be something that was specifically designed to be used by the wider community.

(And it can still be implemented on top of the Git tech, or it doesn’t have to be.)

For me, I love version control and I’m gonna love it in any iteration it appears in. I feel that the next one should have more broader users in mind than a bunch of people who are already really comfortable with their terminals, and they’re reading the email from mailing lists in their terminals already, and unpacking patches by typing out a tar command in a single go.

The new generations of users of GitHub that I witness are not those people. And they’re not me. And they’re not those Linux maintainers.


That’s not all Mislav had to say. Listen to the entire episode to hear the story of switching hub away from Ruby. Also, he shares another unpopular opinion he has about GraphQL and Go. Play it from the start right here 👇

Oh, and don’t forget to subscribe to Go Time in your favorite podcast app so you don’t miss future episodes and insights. ✌️


Discussion

Sign in or Join to comment or subscribe

2020-11-16T17:34:08Z ago

very interesting point. Having also spent many years using git in all sorts of ways, it’s easy to fall into thinking that it’s perfectly fine and people should just learn how to use it. But the comment on responding to a person when they ask a simple git question really resonated with me. It is very hard to give them an answer without looking like you are either messing with them or don’t really know git yourself. And that’s obviously not a good thing.

I totally agree that there should be tools that are more aligned with what people expect and that should “just work” most of the time. Having spent the last 15 minutes thinking what that new toolset might look like, without basically re-creating the svn or tfs of yore, all I deduced is that this is a really tough problem that needs a lot of thinking and a lot of work.

Jerod Santo

Jerod Santo

Omaha, Nebraska

Jerod co-hosts The Changelog, crashes JS Party, and takes out the trash (his old code) once in awhile.

2020-11-16T17:42:21Z ago

But the comment on responding to a person when they ask a simple git question really resonated with me.

This was what got me as well. I’ve definitely had this feeling where I just want to tell them the magic incantation necessary to achieve their goal, but I hope they don’t ask me why that does what it does… because it’s too hard to explain (or sometimes I don’t even know, I’ve just memorized the spell).

Jerod Santo

Jerod Santo

Omaha, Nebraska

Jerod co-hosts The Changelog, crashes JS Party, and takes out the trash (his old code) once in awhile.

2020-11-16T19:36:02Z ago

I was listening to the most recent episode of Practical AI and they actually talked about this exact thing regarding data scientists and their struggles with Git:

And then another detail that shouldn’t be overlooked is most ML practitioners are not super-fluent with Git. They find Git to be kind of a scary interface. Dev ops people find it trivial. In fact, my co-founder Shawn comes from less of an ML background and I’d say more of a dev ops background, and he just constantly makes fun of me for how bad I am at Git. In his view – I just kind of type in random commands into Git until I break everything, and then ask him to fix this stuff…

But I think it was a little bit eye-opening for him when he was designing the versioning, because he’s like “I have to really dumb this down to make something that Lukas can understand and use…”

2020-11-17T23:24:58Z ago

If you’re interested in an alternative to Git, you could check Fossil.

Some interesting documents for you to check:
Quick Start Guide: https://fossil-scm.org/home/doc/trunk/www/quickstart.wiki
Purpose and History of Fossil: https://fossil-scm.org/home/doc/trunk/www/history.md
Fossil versus Git: https://fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki
Rebase Considered Harmful: https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md
Git to Fossil Translation Guide: https://fossil-scm.org/home/doc/trunk/www/gitusers.md

For a whole list of documents see:
Index Of Fossil Documentation: https://fossil-scm.org/home/doc/trunk/www/permutedindex.html

2020-11-19T01:25:50Z ago

I agree using git in the terminal is hard. The same way writing software in binary is hard. That is why we have abstractions, higher level languages, and other applications that abstract gits low level nature. They don’t even have to be GUIs, there are other CLI applications like gitless or lazygit and probably many other.

2020-11-19T02:24:22Z ago

I’ve long been hoping someone would release a “git-lite” which would contain only a set of high-level meta commands to implement basic flow processes. The config file could dictate the flow to use.

Developers on my teams are always getting confused about what their local master branch is for (“delete it! it’s useless!”), why their rebase isn’t finding any changes (“did you remember to fetch first?”), etc., etc., etc.

There’s so many utterly useless aspects of git once a team is stable in a nice feature-branch workflow.

2020-11-19T02:27:19Z ago

And up next, I’ve got to train some business analysts on how to use Git to manage their python reporting scripts using feature branch workflow. They were happy making all changes directly to master until recently, when they discovered that person A’s changes had some bug and thus the contents of master couldn’t directly be released.

Down the rabbit hole we go! 🤣

0:00 / 0:00