4 ms·

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 gre

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".

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".