5 ms·

The problem with git is hardly anyone reads the fucking manual. Git is not hard. The UI is inconsistent, but documented. When you just foist commands onto peopl

The problem with git is hardly anyone reads the fucking manual. Git is not hard. The UI is inconsistent, but documented. When you just foist commands onto people, you can't be surprised when they fall off the happy path and don't have the mental model to understand how to fix it. There's no such thing as "idiot-proofing" for people who don't RTFM. --force-with-lease as a default is a really bad idea. Copying random aliases is a bad idea.

mmmmmbop 4y ago
If one user uses a tool wrong, the user may be at fault. If many users are using a tool wrong, the tool probably doesn't have great UX. Saying "the tool is great, users just need to RTFM" sounds an awful lot like "you're holding it wrong".
- huimang 4y ago
  Industry-specific tooling is different than a consumer product explicitly marketed as "intuitive". This comparison doesn't hold, for me. While I agree that git's UI could be made less cumbersome in some cases, many people in this industry want to use sophisticated tooling without doing due diligence such as reading a manual. Handling code versioning in a distributed manner is not an easy task! I don't expect much from junior developers, but if I have to fix trivial git problems from more "senior" developers, I will have some disdain for them.
- weaksauce 4y ago
  I disagree... git has a fundamental complexity that you can't improve that much on the command line and still have the flexibility and power that it has. I use magit that makes those options a hell of a lot more palatable than they would be on the command line while still affording all the power that you want from pure git. The git-cli has to do everything and there is a fundamental nature of that. I do agree that there are some things that could have been made better with hindsight but that's any project.
  - Arelius 4y ago
    Sure can, for instance a hg-like commit stages system for rebase would prevent a lot of rebase caused issues.
    - weaksauce 4y ago
      > hg-like commit stages system not familiar with what you're referring to... can you elaborate?
      - mmmmmbop 4y ago
        It refers to Mercurial, another really popular distributed revision control system.
      - Arelius 4y ago
        I got the name wrong, it’s phases https://www.mercurial-scm.org/wiki/Phases https://www.mercurial-scm.org/wiki/Phases In short, every commit can be in one of three phases, secret, draft, and public. Commits transition to public when you push them somewhere someone else might depend on them, and rebase won’t allow you to rebase any public commits. Commits can of course be manually transitioned back as a “I know what I’m doing step” but this provides a lot of safety for casual rebases. (Secret just prevents the commit from being accidentally pushed)
- deathanatos 4y ago
  UX can affect incidental complexity, but essential complexity cannot be removed from the problem; this is the same as what some of the sibling comments are getting at. When I interrogate users who aren't grokking git, it's not really git's UX that's the problem, it's far more fundamental: like not understanding (and thus not being able to conceptualize and visualize) that the commit graph is a DAG. Not understanding what "rebase" is, because they have no concept of what the word "base" means: rebase follows trivially from that understanding, if they had it. CLI git has these presentations; it can present the commit graph, though oftentimes companies do such a crap jobs of approaching git history that git is left to render spaghetti. UI tools exist, but face the same spaghetti in, spaghetti out. It's like asking your IDE to make bad code less bad. Worse is people actively promulgate broken "methodologies" that result in these spaghetti graphs, such as the ironically named "A Successful Git Branching Model".
stcroixx 4y ago
I've read the manual several times, but it reads to me more like an in progress design document filled with implementation details, not things an end user should need to even be aware of. I get by fine with 5 or so memorized commands. I made a list of other version control systems I've used in the past and out of the 7, I can only remember one that was complicated enough from an end user perspective to require reading a manual(ClearCase).
nerdponx 4y ago
> The UI is inconsistent, but documented. The problem is that the inconsistency means that you need to constantly refer back to the manual until you have a huge amount of arcana memorized. Not only that, but it's not always easy to find what you're looking for in the manual. Yes, programmers should all at some point read the first few chapters of Pro Git, and at least skim through the "internals" chapter. But idiot-proofing goes beyond babying people who don't want to read docs. Even people who do read docs and care a lot about learning their tools make mistakes and forget things occasionally. > --force-with-lease as a default is a really bad idea. Agreed. > Copying random aliases is a bad idea. Agreed, but looking at other people's aliases to get ideas and borrow useful snippets is a great idea.
lelandfe 4y ago
As a counterargument, git is quite hard, and I see smart engineers make seemingly simple errors frequently. Its documentation is sprawling and verbose, and its UI "porcelain" is frequently terrible. Did you know you can use `git fetch origin master:master` to update an un-checked out local branch? Go find where that's documented: https://git-scm.com/docs/git-fetch https://git-scm.com/docs/git-fetch Spoiler, here's all you get: > The format of a <refspec> parameter is an optional plus +, followed by the source <src>, followed by a colon :, followed by the destination ref <dst>. The colon can be omitted when <dst> is empty. <src> is typically a ref, but it can also be a fully spelled hex object name. Just a truckload of jargon. There's thankfully one code sample to give context, but it's at the bottom of the page – nearly 7,000 pixels of scrolling away from the description of it.
gardenhedge 4y ago
The problem is that it has badly named commands
- chociej 4y ago
  Such as?

mmmmmbop 4y ago

If one user uses a tool wrong, the user may be at fault. If many users are using a tool wrong, the tool probably doesn't have great UX. Saying "the tool is great, users just need to RTFM" sounds an awful lot like "you're holding it wrong".

huimang 4y ago
Industry-specific tooling is different than a consumer product explicitly marketed as "intuitive". This comparison doesn't hold, for me. While I agree that git's UI could be made less cumbersome in some cases, many people in this industry want to use sophisticated tooling without doing due diligence such as reading a manual. Handling code versioning in a distributed manner is not an easy task! I don't expect much from junior developers, but if I have to fix trivial git problems from more "senior" developers, I will have some disdain for them.
weaksauce 4y ago
I disagree... git has a fundamental complexity that you can't improve that much on the command line and still have the flexibility and power that it has. I use magit that makes those options a hell of a lot more palatable than they would be on the command line while still affording all the power that you want from pure git. The git-cli has to do everything and there is a fundamental nature of that. I do agree that there are some things that could have been made better with hindsight but that's any project.
- Arelius 4y ago
  Sure can, for instance a hg-like commit stages system for rebase would prevent a lot of rebase caused issues.
  - weaksauce 4y ago
    > hg-like commit stages system not familiar with what you're referring to... can you elaborate?
    - mmmmmbop 4y ago
      It refers to Mercurial, another really popular distributed revision control system.
    - Arelius 4y ago
      I got the name wrong, it’s phases https://www.mercurial-scm.org/wiki/Phases https://www.mercurial-scm.org/wiki/Phases In short, every commit can be in one of three phases, secret, draft, and public. Commits transition to public when you push them somewhere someone else might depend on them, and rebase won’t allow you to rebase any public commits. Commits can of course be manually transitioned back as a “I know what I’m doing step” but this provides a lot of safety for casual rebases. (Secret just prevents the commit from being accidentally pushed)
deathanatos 4y ago
UX can affect incidental complexity, but essential complexity cannot be removed from the problem; this is the same as what some of the sibling comments are getting at. When I interrogate users who aren't grokking git, it's not really git's UX that's the problem, it's far more fundamental: like not understanding (and thus not being able to conceptualize and visualize) that the commit graph is a DAG. Not understanding what "rebase" is, because they have no concept of what the word "base" means: rebase follows trivially from that understanding, if they had it. CLI git has these presentations; it can present the commit graph, though oftentimes companies do such a crap jobs of approaching git history that git is left to render spaghetti. UI tools exist, but face the same spaghetti in, spaghetti out. It's like asking your IDE to make bad code less bad. Worse is people actively promulgate broken "methodologies" that result in these spaghetti graphs, such as the ironically named "A Successful Git Branching Model".

stcroixx 4y ago

I've read the manual several times, but it reads to me more like an in progress design document filled with implementation details, not things an end user should need to even be aware of. I get by fine with 5 or so memorized commands. I made a list of other version control systems I've used in the past and out of the 7, I can only remember one that was complicated enough from an end user perspective to require reading a manual(ClearCase).

nerdponx 4y ago

> The UI is inconsistent, but documented. The problem is that the inconsistency means that you need to constantly refer back to the manual until you have a huge amount of arcana memorized. Not only that, but it's not always easy to find what you're looking for in the manual. Yes, programmers should all at some point read the first few chapters of Pro Git, and at least skim through the "internals" chapter. But idiot-proofing goes beyond babying people who don't want to read docs. Even people who do read docs and care a lot about learning their tools make mistakes and forget things occasionally. > --force-with-lease as a default is a really bad idea. Agreed. > Copying random aliases is a bad idea. Agreed, but looking at other people's aliases to get ideas and borrow useful snippets is a great idea.

lelandfe 4y ago

As a counterargument, git is quite hard, and I see smart engineers make seemingly simple errors frequently. Its documentation is sprawling and verbose, and its UI "porcelain" is frequently terrible. Did you know you can use `git fetch origin master:master` to update an un-checked out local branch? Go find where that's documented: https://git-scm.com/docs/git-fetch https://git-scm.com/docs/git-fetch Spoiler, here's all you get: > The format of a <refspec> parameter is an optional plus +, followed by the source <src>, followed by a colon :, followed by the destination ref <dst>. The colon can be omitted when <dst> is empty. <src> is typically a ref, but it can also be a fully spelled hex object name. Just a truckload of jargon. There's thankfully one code sample to give context, but it's at the bottom of the page – nearly 7,000 pixels of scrolling away from the description of it.

gardenhedge 4y ago

The problem is that it has badly named commands

chociej 4y ago
Such as?