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.
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. ✌️
Sign in or Join to comment or subscribe
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 co-hosts The Changelog, crashes JS Party, and takes out the trash (his old code) once in awhile.
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 co-hosts The Changelog, crashes JS Party, and takes out the trash (his old code) once in awhile.
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:
Yes. Consider that AI researchers are literally some of the smartest people on the planet. And they struggle hard with it. This should be a giant red flag.
Pijul, and Darcs before it, have been trying to develop a better model for VCS, based on a “mathematically sound theory of patches”. Looks very promising, but I’ll let you judge for yourself.
Magit (https://magit.vc) has made so many powerful Git features discoverable for me that would otherwise be opaque. I believe it solves many of the issues brought up in this article.
Alfonso J. Ramos
You need to indoctrinate people into the church of Emacs first.
And that is a significant barrier unfortunately
Unfortunately, it hasn’t for me. One problem is that I use ediff for looking at changes. I cant do ediff from one tag (all files) to another tag (all files) before committing.
Is it pronounced like ma-git or ma-jit?
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
Is not git flow this sought after abstraction over git commands?
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.
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.
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! 🤣
I think that Plastic SCM made some good decisions, but my client is all in on Git firmwide. So, that’s a moot point for us. https://www.plasticscm.com/
Haven’t used git for a couple of years. Found some great code on github and modified a bit to improve. Wanted to fork and update, then remembered. Oh no I don’t want to go through that again. I’ll just email the author the two files I changed. There has to be another way for the future, like an online file change or similar.
After several years of using git in various ways and learning it hands on with lots of confusion, I agree. git is too difficult, too illogical and has too many commands and ways of working with it. It’s confusing to start working with branches. And then when you think that feature branches and maybe even “git flow” is the way to go, someone says “we will use trunk based development”. And suddelnly, nothing in git makes sense anymore. I thought git was about branches? “Oh no good lord, branches are evil my dear”. Ok then, so how does this git thing work… I could go on. What if code version management was like collaborating in a Google Doc? That would be nice and easy for everyone to understand.
Git is a brilliant data model that we hack into being a code repo. It was designed from the model backwards, not the use cases inwards.
It could very well be that Git simply needs a new set of commands, and a new set of explenations and that would mostly be it.
It could also be that the nature of this really isn’t suited to just command line. We may need command line, with ‘visual reference’ (imagine a combined UI). I say this becuase the first time I saw animated commits, I learned a bunch of things I didn’t know. The ‘command line’ has this ugly problem that … you often ‘don’t know what you don’t know’ and this creates problems.
Common things like ‘undo’ need to be done, especially in a way that isn’t confused with the kind of ‘undo, but really we’re adding a commit so you can undo the undo’ etc..
Git doesn’t seem to focus a lot on the 80/20 rule, more like the 99/1 rule where the vast, vast majority of the time you want to do simple things, but they extend to deeply into the woods where you can get into trouble.
Finally - git was designed for Open Source. Most projects are not. Most projects have a team. Something that was designed to focus on basic cases, team oriented - but then had extended or secondary functionality to support open source would be better.
People vastly underestimate the real cost of ownership of Git, the confusion, problems, research, lookups etc. that it ultimately creates. To the point that I consider it a borderline liability.
An easier Git already exists, it’s called Mercurial. More sensible CLI especially when coming from SVN, a nice GUI client (TortoiseHg), just overall nicer to work with. I feel like Git only became that popular because the geeks like to worship Torvalds and because of GitHub. Today Mercurial is the nicer, more straight forward option. Fight me. :p
added in error
This discusses how to stop tracking a file. https://stackoverflow.com/questions/1274057/how-do-i-make-git-forget-about-a-file-that-was-tracked-but-is-now-in-gitignore/1274447#1274447. I want to right click the file and choose a command from a context menu. I don’t want to spend hours reading conflicting ideas on how to accomplish so minor.