I've always found it interesting that Git gets a pass for its horrible UX by so many devs. The programming community wants to provide too many options for _everything_. If there's a tool you don't like, there are probably 10 other versions that do similar enough things that you can just switch. Devs are harshly critical of tools. And yet, with Git, the response just seems to be "if you don't like it you must just not _get it_." Which, I guess is fair, but I don't particularly understand why everyone has to "get it"? Why can't we expect a tool that's used by so many be intuitive? Or at least, _more_ intuitive? It feels a bit like hazing at this point. The post recently about `git undo` was great, I think, because of the frequency with which users encounter surprising and unintended behavior.
It continues to be kind of frustrating to me. It feels like a tool that should be wrapped in something else and never even brought up to 99% of users. A half finished idea on productivity and team centric version control (to get ahead of comments: I know it's not designed to be that, but that's how it's very frequently used).
>And yet, with Git, the response just seems to be "if you don't like it you must just not _get it_." Which, I guess is fair, but I don't particularly understand why everyone has to "get it"? Why can't we expect a tool that's used by so many be intuitive?
There are lots of UIs for git - many people on this forum will advocate for using one. My personal experience is that a UI manages to over-simplify the git workflow. It never quite allows you to perform all of the useful tasks you want, unless your use of git is very basic.
In a more general sense, git can also be considered quite conceptually simple; "getting it" is not the real problem most users have. The confusion about what commands do comes from the fact that users learn the tool backwards. No job bothers to teach a junior developer about the DAG and what commits, branches, and refs really are. Instead, they are forced to start with git's large and crufty CLI - so it's no surprise that it's hard to pick up any intuition about what's going on.
And that's a problem with lots of technical teaching, not just git. Since the focus is on getting immediate observable results, and not on conceptual understanding, users tend to learn how to use tools instead of how they work. That creates a culture of "I don't know what this is doing, and I'm too scared to mess with it" - basically the anti-hacker mentality.
> And that's a problem with lots of technical teaching, not just git. Since the focus is on getting immediate observable results, and not on conceptual understanding, users tend to learn how to use tools instead of how they work. That creates a culture of "I don't know what this is doing, and I'm too scared to mess with it" - basically the anti-hacker mentality.
yeah I guess I don't really align with the "Developers must learn the internals of all of the technology they are required to touch", and I don't really agree with the sentiment that that decision disqualifies one from "hacker mentality".
>I don't really align with the "Developers must learn the internals of all of the technology they are required to touch"
The DAG, commits, refs, etc. are not the "internals" of git - they are the basic building blocks of its mental model. Without them, there is no way to understand what git is doing - so it's no surprise many people think git is unintuitive, because they aren't taught what those concepts are.
The thing I'm saying is counter to the hacker mentality is using a tool as a black box, without understanding what it does and what it is trying to do. You don't have to read the code and know all the technical details.
Lots of users treat git as a small set of known commands that they execute in sequence until the repo is in the state they want; and any deviation from that happy path is met with a repo wipe and re-clone. A hacker should be happy to play around with various man pages and commands to build an understanding of what each command really does - and then be able to fearlessly mix and match commands, because they know how they are affecting the repo at each step.
> The thing I'm saying is counter to the hacker mentality is using a tool as a black box, without understanding what it does and what it is trying to do. You don't have to read the code and know all the technical details.
And I'm saying that this statement is just hustle culture nonsense.
> A hacker should be happy to play around with various man pages and commands to build an understanding of what each command really does - and then be able to fearlessly mix and match commands, because they know how they are affecting the repo at each step.
No true scotsman would use git without reading books about it!
This is just nonsense. Gatekeeping holier than thou nonsense.
I use SmartGit (there are many other visual tools), as I have no interest in untangling the utterly hostile Git command-line interface. Using the terminal to stage chunks of a file? No thanks.
I feel no embarrassment about it either. You may pride yourself in using Vim, while working on a multi-thousand-file project. You are a power user, good for you. Now go collect other time-wasting useless accolades, like Pokemons.
It's not like there aren't more than ten different tools that do approximately what git does, but a little differently. There are also dozens of UIs on top of git. So the response to git's UI is not uniformly "RTFM", many people tried to provide alternatives.
It continues to be kind of frustrating to me. It feels like a tool that should be wrapped in something else and never even brought up to 99% of users. A half finished idea on productivity and team centric version control (to get ahead of comments: I know it's not designed to be that, but that's how it's very frequently used).