What makes Git so hard to use?

The git UI built into JetBrains IDEs is the only thing that makes git work for me. It's very intuitive to use.

Cmd+K to commit changes. There's a list of all files changed, organized by file hierarchy. You can click any of them to get an embedded editor and you can edit right from there.

There's a VCS pane you can pop up to view commits from any of the branches you have pulled without switching, you can select commits and right click > cherry pick to pull them into your current branch.

And the diff resolver is perfect. 3 vertical panes with the incoming and local changes on the left and right, and center is the merged product. You can press arrows on each side to bring those changes into the center, it shows right where they'll go with colored highlighting before you even make any changes. And the center is once again an editor so you can just manually type in it to resolve conflicts too.

Git's mental framework is so visual for me, it just seems like a better experience in a GUI. Especially one as well-thought-out and intuitive as what JetBrains came up with.

If I had a dollar for every time someone complains about how git is unfriendly, I'd have enough to buy Twitter.

I've been using version control systems since CVS and I've found git the easiest and most sensible thing to use. Admittedly, some of the commands reflect internal data structures and concepts rather than what a user would want to do but that's just a learning curve issue. To address specific points.

1. Of the 157 commands, there are maybe 10 or so that one would need on most days and maybe 5 or 6 others when things go awry. Perhaps another half dozen for specific workflows but that's it. How many times do people use git daemon or git instaweb or git fsck? Why are these listed there? I do git trainings and teach a handful of commands in half a day which are sufficient to get people started.

2. The index has been extremely useful to me when I code for a while and then later need to commit only some files or parts of files into separate commits. This is a "good thing". The workflow which the author is suggesting would be like a "git commit -am ... && git push" which is not ideal

3. There are two destructive commands. git checkout and git reset when you've not committed. These two can discard uncommitted code in the working tree and you'll lose them. Once you've committed, it's possible to undo almost anything using the reflogs. They're very useful and worth learning how to navigate and use. Even rebase --hard can be undone by switching to a previous reference.

I think this is a deliberate decision. git is a power tool that sacrifices protecting the user from mistakes to give the user fine grained power over a project. A tool that hides these things from a user and tries to wrap the whole thing in a veneer of user friendliness might be good if engineered properly but my feeling that is that it wouldn't be worth the sacrifice.

Highflux itself advertises several things like " Automatic commit on every editor save." which I'm not sure are good ideas. I hit save repeatedly while working. Each one of those saves is not meant to be a commit.

The idea you somehow NEED to learn all the commands as a reason why it's hard is crazy.

Adding HighFlow on top will just add more commands because inevitably there'll be a point where some HighFlow abstraction fails and you have to go to Git anyway to fix it.

Also I can see that HighFlux runs as a daemon. That seems sub-optimal - sucking up my CPU all the time on the off chance I want to code something is not great.

It doesn't seem like HighFlow supports actual remote repositories except GitHub. Which is the entire point of a distributed version control system - to be distributed.

I think HighFlux is designed to solve a very limited subset of Git's usage and so they've stripped out a lot of useful commands they don't use and so they can ship a product.

But in the real world people will need this and their simple vision will crumble back to the complexity of Git (or close).

Gitless folks did some actual user research years ago, getting feedbacks on various tasks difficulty, and they have a nice theory of api misfit, I really recommend the read for more structured speculation of why git is hard: https://spderosso.github.io/oopsla16.pdf

I think git is hard because 99% of the time it just works with little to no required understanding of what you are actually doing. That is to say that git is actually too easy... until it isn't. Once you hit a scenario where you get off the happy path, that is when git becomes hard.

I find this message hard to get because git is dramatically easier to use and more tolerant of mistakes than previous version control packages. It's certainly true that looking at the man pages could drive almost anybody insane but working from a cookbook it is very easy. (Most of the time I think it is a mistake to "Google" for answers but rather you should learn to look things up in the official docs. Git is a counterexample)

Visual Source Safe would outright die when your repository overflowed a 32 bit file.

Changing a wrong commit message was almost impossible with CVS.

I push into the wrong branch and make other mistakes like that sometimes with git and I have no fear about it at all and little stress because I can always look in the cookbook and find the recipe to fix it.

Git also is the basis for numerous tools such as GitHub that are accessible to non-technical users. Git is the only version control system I've seen that can be used like that.

It's hard because nobody thinks of it as a part of their job. Like coding is to some people, git is often a thing that you just have to do.

So then you don't learn how it really works, and you get weird problems because you never formed the right model in your mind.

It's also the case that there's a few commands you use a lot, but a lot of commands that you reach for only in specific cases. This creates the impression that it's too complicated, because as soon as you go off road you get stuck.

Disagree that git is hard to use. It's fairly complex, I'll admit, however it's pretty much all "necessary complexity".

Occasionally, I'll see articles talk about "fixing" git by eg. removing the staging area, or something like that... but the staging area is great! It's literally a feature I was dreaming about when I used Mercurial.

I definitely think there's room for a more intuitive solution. I would rate the git learning curve as "medium-easy"

Honestly, I have loved git ever since I started using it.

- I use sourcetree for committing, it is a great UI tool for seeing your commit graph and just entering commit messages / partial commits / selecting which files to commit

- I use command line for all pulling/merging/fetching/branching etc. Git command line is just so simple IMO (once you get a short intro to it).

- Repairing issues in git is honestly not difficult.

- The hardest part of git is branching, merge conflicts, and squashing. When you combine all 3 is where it gets challenging if you don't know how to avoid any gochas. But it does make for nice revision history.

So I guess if you are doing some crazy complicated git stuff, I can't speak to that. But in 8 years I can definitively say I have only enjoyed git, and have often been the person to debug issues with people using git, and it is always a fairly simple thing to un-screw things up.

Criticism: push -f is definitely a dangerous operation. I can see why the mercurial team said no history rewriting period.

> Git has been trying to create less confusing commands (like splitting git checkout into git switch and git restore)

I really don't know why anyone would use these new "easy" commands. They don't feel that much better and their existence irks me because now there's even more ways to do the same thing.

I agree that git is very non-intuitive to learn when you first start working with it, and it's great to see a number of teams trying to make this better.

Hah, just today I was wondering how come no ex-Googlers tried to tackle VCS, and now here it is, apparently by ex-Googlers.

Dev experience at Google kinda sucks for the most part, but one thing that works amazingly well is VCS. You never even have to think about it, it literally just works, and it works at very large scale (monorepo for all of Google).

It’s just: 1. Create a workspace 2. Submit the changes in your workspace

And that’s it. I hate going back to the mess that is Git.

One misunderstanding I had that about git was thinking that branches contained more than one commit, while actually they're kind of like a movable tag that points to a single commit.

Learning what rebase actually did and the difference between reset soft/hard/mixed along with using the reflog to get back to previous states made git a lot more understandable to me.

That said, if you want to see how insanely complex git is, try reading its many man pages.

An underlying problem is git is a file system on top of a file system.

If every time the journal / write-ahead log was flushed, the files were rehashed, we wouldn't need index vs non-index so much.

We would use normal commands to sync two work trees one being what we have, and one being what we want to commit.

Instead of .gitignore we simply should have temp files elsewhere.

Basically the file system is a bad abstraction and all VCS is ad-hoc work around it.

One thing I wish git did differently was to have an atomic commit-and-push operation. I'd like to prepare my commit as normal, but when its ready, it pushes that commit as well, but if that push fails, it undoes the commit.

Why? I recently configured my github to use a hidden email address. To this end, it required me to use a github.com email address it generated for my commits. I set it up and started pushing commits, everyone was happy.

Then I went to a different folder that had a separate clone of the same repo, and I forgot I had configured github this way. I made some changes and did the usual commit-and-push but github rejected it. I had used the wrong email. Oops.

But now I had a problem. My local repo had the commit with the wrong email address in place and I didn't know to change it. I couldn't make a new commit with the new email as the old one was still there. I looked up how to revert already committed commits and long story short I did it wrong and deleted all my recent changes.

When I realised that branches were just labels pointing to a commit, instead of a an actual "branch" ie a group of commits, then everything made a lot more sense. I still kinda wish branches were more groups of commits, so that if you have multiple branches on top of each other they can automatically/more easily keep up to date.

I feel an engineer is incomplete without knowing their daily tools more than the basics. I find it frustrating to work with people who don't make the effort to learn git. Urging them to relax and take some time to read up or go through guides. They are fine spending time learning new languages or frameworks on their spare time, that they then want to bring into work. But spending a weekend reading some blogs about git or the short manuals is somehow tedious. Many times they can't write a proper commit message, and when they get a merge conflict they kick and scream, and you have to solve it for them. It's not that hard to go from a beginner to an intermediate user of git. And the trade-off can be quite significant with the confidence in managing around git. Learn from the CLI first, then jump onto tools that fit you (shout-out to magit!)

With the amount of Git-skeptical articles that have been popping up recently, I'm starting to get worried that someones gonna come along, make some fancy and shiny centralised VCS, market it like the cure to cancer, and all the new developers will eat it up and 8 years after it'll be a bloated hellscape.

“Git gets easier once you get the basic idea that branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space.”

— Isaac Wolkerstorfer

http://twitter.com/agnoster/status/44636629423497217

My biggest git gripe is that its cognitive load can get high pretty quickly, while really for a VCS you want it to be powerful but stupid easy all the time. For example, if you try to find info on best practices on non-trivial git stuff, you find compelling and well-articulated arguments that are diametrically opposed to each other (see: rebasing).

I use git constantly and hardly ever have problems with it, but only because I use a tiny fraction of it and I religiously follow an exact process every time. I've had people tell me all sorts of reasons why my approach is not good, and they're probably right, but it's really nice to not have to give my VCS very much thought 99% of the time.

> Git commands are too many, too low-level and hard to understand.

Most of these are 'plumbing' commands, not 'porcelain' commands. Perhaps the author should have read the book on the Git website¹, as it explains this.

> Git tracks 4 versions of files, instead of just "my" version and "the team's" version.

This is because it's a distributed version control system, not just a tool to upload files to GitHub.

It seems like the author hasn't even taken the time to understand the basics of Git, and its design goals, before writing this ignorant screed.

＿

¹ https://git-scm.com/book/en/v2

The lack of a `git undo` is the reason why I’m afraid to try git commands I haven’t yet needed. I can’t exactly “move fast and break things” if I’m always two errant commands away from receiving unwanted attention from my team.

> Git doesn't let us safely experiment

Isn’t this one of the main purposes of branching?

Also git is easy to use. You can ignore the non-basic commands as a small team or solo dev, and there are plenty of GUIs to help with UX

For me, there were a few weirdisms in the wording of some commands but they weren't show-stoppers. I think for people like me who came from centralised CVSs, it was that Git was actually more powerful so it seemed a bit overwhelming or un-necessarily complicated.

Once you realise why git is like that, I haven't found it that bad.

It's no different than someone who has only ever ridden a bicycle asking why a motorbike is so hard to use. Because it does more stuff.

I love writing hardcore C code full or pointers and cross-calls but for some reason I can't get bothered with semi-advanced Git.

There's a dread, a fatigue... I got burned merging (or was it rebasing?) and now I often just copy my folder to make a temp branch.

By the way, how do you extract a file from an old commit without checking out (and crushing your current files..) ? No hassle with the old folder-copy-tech !

I guess git seems complicated when you go deeper into it. I just learnt the basic stuff (add, commit, push, pull, checkout and create branch, status, stash and reset merge) and haven't gone beyond it. I remember seeing some post on HN on how to make git easier to use and the person had written some aliases of commands that I had never even seen/used before!

I am happy to see startups working on improving git usability. Git is so hard to use when things get out of the simple path.

On top of all the other concepts being introduced at once, staging seems to be a difficult one.

There's only really ~5 day-to-day commands that you need to know to use it. Going past that is mostly unnecessary and frankly pretty pointless.

checkout, pull, commit, push and reset if you make a mistake. I'm not including one time commands like clone and init.

My favorite thing about git is that it allows you to solve different processes in different ways but basically with the same logic. everything done affects a history and all one has to do is focus on the history.

It's always been a UX problem and it's gotten much better.

Here's something I posted 7 years ago over on a reddit comment thread about it

---8<---

I've been running a git hater twitter account for years and have had git use me, or me use it, for 8. (https://mobile.twitter.com/githater)

I "grok" the concepts. I do not however, get the broken command line interface. How is an error message like this at all helpful:

git push -u origin master

error: src refspec master does not match any.

That's not even a proper english sentence.

Here's an example of the three counterintuitive undiscoverable ways to do one common thing that everyone wants; be able to push and pull from a branch without specifying it each time.

git branch m

THEN

git checkout m

THEN

git push -u origin m

OR

git branch --set-upstream=m origin/m

Or if you want

git checkout --track -b m origin/m

How do you push to a branch?

git push origin m

how do you delete a REMOTE branch?! Same thing, but prefix it with a colon

git push origin :m

How do you delete a LOCAL branch? Use a different command, with a different option

git branch -d m

Show useful information about tags? What about sorting them, by date. Sounds typical, common if you dare say... If you think it's in git-tag, your princess is in another castle. You need git-for-each-ref. Here's the simple to remember magic:

git for-each-ref --format="%(taggerdate): %(refname)" --sort=-taggerdate --count=10 refs/tags

So easy to use, no wonder it's number 1.

how do you rebase? It's a simple task!

git rebate --onto something commit id that is one before where you actually start from [ space, not 2 dots like everything else ] commit id where you want to end at ...

Great, now you are in a "detached head" state. So the rebase onto didn't actually rebase on to it ... yeah ... about that...

---8<--- (from https://www.reddit.com/r/programming/comments/3qt28h/xkcd_15...)

So in conclusion, the documentation was full of arcane discussions in domain specific jargon. The interface was wildly inconsistent and asymmetrical and the errors were cryptic and unhelpful.

Here's a fun one. If you just git init and then have multiple users start pushing, you know, like the documentation encourages you to do, the objects database files get the ownership of the person pushing upstream and then can lead to wildly cryptic intermittent permission denied errors because the database is actually just a bunch of unix files. Yes there's many ways to fix this, but that's not the point. Why is a deep dive discovery process needed to make basic things work in obvious ways? It's a Heathkit when all you need is a calculator.

When you expressed these complaints people would respond with theoretical introductions to branching and ASCII art diagrams.

It was all no good. I even tried some futile attempts over 10 years ago to contribute to clean things up.

The problem was I was unable to convince people deeply intimate with the codebase that there were hostile user patterns that could be alleviated with a bit of expository writing. All the cryptic jargon was utterly clear, exact and concise to someone who's spent 1,000 hours on the source. "Many people find these interface patterns confusing" was met with "we have academic level documentation with diagrams". Alright. Useless.

It's gotten a lot better though.

I think some of their 'issues' could be resolved by learning things like git reflog (e.g. the 'undo' command request)

The article mentions a lack of "undo" with git. This is one of the reasons I use a GUI git tool - specifically I use Tower for Mac right now for most of my day to day git. I still CLI stuff now and then, and Tower still spits out messages that force me to command line when it gets itself in to a state (rebase/conflict resolution sometimes). I can't recall other GUI git tools having an undo, but maybe some do now?

tldr: the 'undo' in Tower has been really handy for me over the past few years. Really handy.

IMO got is intuitive and easy to use therefore the title is subjective and incorrect. Please update to be less of an opinion.

Looks great. I will give it a try

I think is very easy to use