Why is git the hardest to grok for most developers compared to almost anything else in the web dev ecosystem? It always feels like a tool with very less or very leaky abstractions.
Is it because the complexity is really needed, or if papering over them and making it user friendly has failed? For example, you won't find a cheat sheet of SQL commands submitted and upvoted so many times on HN, even though SQL implementation and internals are very complicated. Reason being it's able to hide the implementation details and abstract it away.
At the very least the terminology in git is very confusing. Especially 'checkout' for people who came from a SVN/CVS background.
For me it's because it's highly stateful, and in ways that are mostly invisible. You have to keep in your head whatever state your repository is currently in so you know what actions you can/should take next. And if you wander off into a bad state, it can be nearly impossible to chart your way back blind unless you've been there a few times before. It's like playing the world's worst text-based adventure game.
I think the above problems mainly come down to the fact that it should be a GUI but isn't. Which is why so many GUIs are built on top of it, but then they're shaky because they depend on a CLI which is itself trying to be GUI-like. I would honestly take a text-mode GUI over what we have, and I don't even use text-mode GUIs normally.
I always say, git is the worst VCS except for all the other ones.
I immediately liked "git the architecture", but stayed away from it a long time because of what I though a poor user experience. I attributed this to the clunky CLI, but you're right that the richer state was also part of the problem for me when using the CLI. With the index (and also stashes) there's more state than in subversion for example, and it must be managed properly.
Magit (https://magit.vc) solved both problems as far as I'm concerned. It shows the current git state in a clean, easy to explore way. It also makes it easy to change it as needed. It also hides most of the CLI oddities by building commands for you from a well designed menu system --- some weirdness will remain: bypassing hooks is "-n" for a commit and "-h" for a push for example. That's the price of staying close to the CLI. And the result commands can be seen and checked if one wants to. Magit makes the git options visible and discoverable in a compact way, and expressing what to do easier.
To me that made the difference from preferring sticking with subversion or using mercurial, to preferring git today. In particular, the index is a very powerful tool to break a lot of changes in a set of nice "atomic" commits once done. I really appreciate it now that I can easily visualize it and control what's there, and trivially sends specific line changes to it.
Sure, Magit is tied to Emacs. But it's possible to use Emacs just for Magit. I'd recommend anyone having problems with git UX to have a try. Some people may joke that now they have 2 problems, and that may be true ;), but for someone that can deal with the Emacs basics I'm positive Magit will be a plus to deal with git.
Because unfortunately, network effects, Torvalds' influence and the rise of Github made a tool which is a UI nightmare, and only really makes sense for really advanced users, displace all the alternatives.
And we now have plenty of people who would just need a knife to cut fruit, and are instead cutting their fruit with a surgery-grade remote-controlled high-precision cutting robot, and spending lots of hours learning the fine detail on how to operate such a robot (trying to get by with only 4 or 5 buttons of the hundreds of buttons and knobs in the robot, but often failing and needing to look at the manual to undo their errors), because you need to upload your fruit "surgery-grade-remote-controlled-high-precision-cutting-robot-fruit-hub" if you want it to have visibility.
Hg is much more intuitive and I'd say 90% of git users would be happier in an alternative timeline where it had triumphed. Darn, even SVN was much more intuitive UI wise, even if of course it falls short on functionality these days.
It's not just a leaky abstraction, there is no abstraction!
It's the opposite of user-centric design, like a car with no body where you adjust the gasoline pump, the transmission, the amount of oil etc. yourself.
There's an underlying model, which is tricky but not rocket science - and all actions on that model can have a bunch of non-obvious state changes and side-effects.
It's just complicated enough that it's hard to keep track of the models+statefullness without some expertise, experience and thought.
The first time I saw an 'animation' of what was going on with various commands, it blew my mind how much I learned as I saw things happening.
The language we uses is often not very specific and leaves out important details.
We use it because there's a kind of simple brilliance to the underlying model, it's very fast, very robust, and works well for open source.
That said, I wish there was a git optimized for teams and with better abstraction.
I'm still in camp subversion, my main gripe about git is the lack of a linear rev number for master. The rest of it is complexity you can either take or leave.
I've thought about writing a subversion compatibility scripts overlay for git, just to make my live easier.
> my main gripe about git is the lack of a linear rev number for master
Unless you are using git as a centralised SCM, the concept of a linear revision doesn't quite match up.
Of course many workflows between different branch and people do eventually end up with there being a "master master" (or a main main to use more up-to-date terminology), and workflows for single dev projects naturally do, perhaps in those cases you could wrap relevant git commands in something that increments a build number stored in a file before relevent actions.
It perhaps do away with a simple increasing revision number and use the date of merge on that branch, which would at least always be increasing.
Is it because of trying to use too many features? Or working with large groups and everyone trying to do too much?
I've been through 3 source control systems now, and Git is by far the easiest. I only branch, clone/init/add/commit/push/pull and merge. (And now most through the gui in vscode) There are some minor fixes I've had to look up, but it's rare.
Almost all the complaints I hear about are from very obscure commands and situations I've never seen.
Is using Git in a simple way the answer to everyone's problems with it?
Using Git only in a simple way isn't quite the answer to problems, because if you make a mistake, you'll still need to use non-simple commands to get yourself out of it.
When my level of understanding of git was "add/commit/push/pull", if ever I made a mistake, I'd then have to try a more sophisticated command which would then risk making another mistake.
At one point you'll have a long-living feature branch which you'll have to periodically rebase with the main branch, and this is where nightmares begin.
I'm an expert in git, but at a glance I don't see what you're trying to do here. It's like dumping an alphabetical list of methods on someone. An expert already knows them, and it's a weird way to present it to someone new to coding.
All this information is already natively available in the help menus, and new people should probably generally stick to things like egit if they're completely lost and need a beginning grasp imo.
Why isn’t git fetch included? Having worked with a quite a lot of developers who don’t understand git, many of whom know so many things I don’t when it comes to so many other domains of dev knowledge, it always astonishes me that people don’t understand what is happening underneath when they do a git pull.
I feel like the two main reasons people don’t understand git is that they start by using a GUI instead of starting with the command line, and that they don’t understand fetch.
My bad. It looks quite a useful reference but suspect it would be overwhelming if you haven’t already understand the key ideas.
My point was really that understanding git doesn’t need to be overly complicated in the end, if you just focus on key concepts, such as the notion of git fetch updating the remote branches within the local repository (and hence status being a reflection of that)
The website captures left/right arrow indiscriminately of modifiers, causing short cuts like Alt+Left and Alt+Right to go back/forth in the browser history.
If the author is reading, just an observation; because the local repository column is pretty solidly coloured, I kept confusing it with the selected column.
A really nice illustration, but it's a bit unclear on a few things (especially stashes), and it can give off the impression that git commits not only track "changes" but in fact are changes instead of what they really are, that is, snapshots of the repository at a particular moment.
This shows only the headings of the 5 categories and then empty bars on Firefox... could you offer a pdf or picture as an alternative download for people who don't use (I suppose) Google Chrome?
You may be blocking the javascript needed for this page to render properly. I'm on Firefox 92.0.1, saw what you saw at first, then in uMatrix I enabled "script" coming from "code.jquery.com". Page renders fine now.
Is it because the complexity is really needed, or if papering over them and making it user friendly has failed? For example, you won't find a cheat sheet of SQL commands submitted and upvoted so many times on HN, even though SQL implementation and internals are very complicated. Reason being it's able to hide the implementation details and abstract it away.
At the very least the terminology in git is very confusing. Especially 'checkout' for people who came from a SVN/CVS background.