3 ms·

The Terrible UX of Git (2021)

7 points by tipiirai 4y ago

tipiirai 4y ago
Wanted to share this because I find git UX terrible and share all the points on the article and the post was not found here in HN.
jeffreygoesto 4y ago
Speculation: git's _U_X is considered terrible, because it was not built to be used by _U_sers in the first place? It started as an opinionated tool for an opinionated workflow done by a small number of peers?
- vba616 4y ago
  >an opinionated tool for an opinionated workflow done by a small number of peers This is a less than clear way of saying its purpose is gatekeeping, discouraging the "wrong sort of people". I'm not saying that gatekeeping is always wrong, or that even when it's wrong that it's worth fighting to change a culture rather than going off and doing your own thing. But I do think it's worth consciously considering whether the particular culture of Linux kernel development has to transfer to all other software projects.
  - jeffreygoesto 4y ago
    I did not want to imply that. Rather that it was a tool for a small number of people with a certain mindset, that was never adapted as adoption grew.
    - vba616 4y ago
      I thought that you were repeating or paraphrasing a widespread description originating with Linus so I wasn't really speaking to your intentions.
- somat 4y ago
  Git's ui is bad because it was not planned out. people added features as they needed them without enough gatekeeping to maintain consistency. Linux in general is notorious for it's bad interfaces(I'm looking at you iptables) I regard fossil as the gold standard of a good version control command line interface. but it has the benefit of having effectively one developer. but even hg has a more consistent interface. did they just care more? perhaps it was the benefit of learning from the mistakes of git?
  - Someone 4y ago
    > even hg has a more consistent interface. did they just care more? perhaps it was the benefit of learning from the mistakes of git? If they learned from the mistakes of git, they must have learned fast. According to Wikipedia, the first release of mercurial was on April 19, 2005 (https://en.wikipedia.org/wiki/Mercurial https://en.wikipedia.org/wiki/Mercurial), just 12 days after the first release of git on April 7, 2005 (https://en.wikipedia.org/wiki/Git https://en.wikipedia.org/wiki/Git) Or did they do what git should have done: early on bite the bullet for a complete overhaul of the CLI, making the various options consistent?
v3ss0n 4y ago
Hg was a lot more better, we only used hg+bitbucket until bitbucket killed hg support and we had to move to git. I hope The new sapling by meta got adopted.
dim13 4y ago
https://gameoftrees.org/ https://gameoftrees.org/
veidr 4y ago
I am pretty weirded out by all the fellow software engineers I meet who just like, use git (the CLI program) directly. It seems crazy to me, like just writing every loop in assembly language because, you know, it's a loop, might be performance-sensitive. For day to day work, I use tools built on top of git, that present a much simpler workflow that is a tiny subset of what the CLI git program offers. Those tools include GitHub, Fork, SmartGit, our bug tracker's "New PR" feature, and e.g. my colleague's `pr-to-pr.sh` script, etc. I include among those "tools" the few CLI commands for things I do so often, it's not extra cognitive waste — simple things like "git pull", "git push", and maybe "git checkout -b hoge-hoge-branch". So it's not literally true that I don't use the git CLI command, but it is effectively true. To me, using git directly (aside from those few special cases) is like an "oh no, emergency!" type of action. Which does happen; I accidentally pushed commits to my local `main` branch or whatever, then I google it with kagi.com and like, carefully enter the right series of commands to rescue my work. But that shit would happen like, all the time if I just used git CLI as my main interface to git.
- turtleyacht 4y ago
  > e.g. my colleague's `pr-to-pr.sh` script That saves typing for sure, especially if it can generate a story ID too (via Jira API, for example). The script itself represents knowledge just in case someone forgets. > [why] use git (the CLI program) directly > include among those "tools" the few CLI commands for things I do so often > not extra cognitive waste Admittedly, that's why: fear of forgetting the simplest invocation. So strong that somehow my brain doesn't think, "Okay, write a shell script wrapper around this." But also, seeing .gitconfig of others, "I really shouldn't type this all out each time." And then, "Where can I put this so it's mine?"
dtagames 4y ago
The Git CLI is terrifying and awful. It's far too easy to clobber your own work -- and that of others -- when the whole point of it was to prevent that. While you still need to really deeply understand several git concepts to use it, GitKraken[0] is the best GUI tool I've used in daily practice. It integrates well with git hosts and has an attractive and mostly comprehensible interface. Accordingly, it isn't free (except for public repos). [0] https://gitkraken.com https://gitkraken.com

7 points by tipiirai 4y ago

Wanted to share this because I find git UX terrible and share all the points on the article and the post was not found here in HN.

jeffreygoesto 4y ago

Speculation: git's _U_X is considered terrible, because it was not built to be used by _U_sers in the first place? It started as an opinionated tool for an opinionated workflow done by a small number of peers?

vba616 4y ago
>an opinionated tool for an opinionated workflow done by a small number of peers This is a less than clear way of saying its purpose is gatekeeping, discouraging the "wrong sort of people". I'm not saying that gatekeeping is always wrong, or that even when it's wrong that it's worth fighting to change a culture rather than going off and doing your own thing. But I do think it's worth consciously considering whether the particular culture of Linux kernel development has to transfer to all other software projects.
- jeffreygoesto 4y ago
  I did not want to imply that. Rather that it was a tool for a small number of people with a certain mindset, that was never adapted as adoption grew.
  - vba616 4y ago
    I thought that you were repeating or paraphrasing a widespread description originating with Linus so I wasn't really speaking to your intentions.
somat 4y ago
Git's ui is bad because it was not planned out. people added features as they needed them without enough gatekeeping to maintain consistency. Linux in general is notorious for it's bad interfaces(I'm looking at you iptables) I regard fossil as the gold standard of a good version control command line interface. but it has the benefit of having effectively one developer. but even hg has a more consistent interface. did they just care more? perhaps it was the benefit of learning from the mistakes of git?
- Someone 4y ago
  > even hg has a more consistent interface. did they just care more? perhaps it was the benefit of learning from the mistakes of git? If they learned from the mistakes of git, they must have learned fast. According to Wikipedia, the first release of mercurial was on April 19, 2005 (https://en.wikipedia.org/wiki/Mercurial https://en.wikipedia.org/wiki/Mercurial), just 12 days after the first release of git on April 7, 2005 (https://en.wikipedia.org/wiki/Git https://en.wikipedia.org/wiki/Git) Or did they do what git should have done: early on bite the bullet for a complete overhaul of the CLI, making the various options consistent?

v3ss0n 4y ago

Hg was a lot more better, we only used hg+bitbucket until bitbucket killed hg support and we had to move to git. I hope The new sapling by meta got adopted.

dim13 4y ago

https://gameoftrees.org/ https://gameoftrees.org/

veidr 4y ago

I am pretty weirded out by all the fellow software engineers I meet who just like, use git (the CLI program) directly. It seems crazy to me, like just writing every loop in assembly language because, you know, it's a loop, might be performance-sensitive. For day to day work, I use tools built on top of git, that present a much simpler workflow that is a tiny subset of what the CLI git program offers. Those tools include GitHub, Fork, SmartGit, our bug tracker's "New PR" feature, and e.g. my colleague's `pr-to-pr.sh` script, etc. I include among those "tools" the few CLI commands for things I do so often, it's not extra cognitive waste — simple things like "git pull", "git push", and maybe "git checkout -b hoge-hoge-branch". So it's not literally true that I don't use the git CLI command, but it is effectively true. To me, using git directly (aside from those few special cases) is like an "oh no, emergency!" type of action. Which does happen; I accidentally pushed commits to my local `main` branch or whatever, then I google it with kagi.com and like, carefully enter the right series of commands to rescue my work. But that shit would happen like, all the time if I just used git CLI as my main interface to git.

turtleyacht 4y ago
> e.g. my colleague's `pr-to-pr.sh` script That saves typing for sure, especially if it can generate a story ID too (via Jira API, for example). The script itself represents knowledge just in case someone forgets. > [why] use git (the CLI program) directly > include among those "tools" the few CLI commands for things I do so often > not extra cognitive waste Admittedly, that's why: fear of forgetting the simplest invocation. So strong that somehow my brain doesn't think, "Okay, write a shell script wrapper around this." But also, seeing .gitconfig of others, "I really shouldn't type this all out each time." And then, "Where can I put this so it's mine?"

dtagames 4y ago

The Git CLI is terrifying and awful. It's far too easy to clobber your own work -- and that of others -- when the whole point of it was to prevent that. While you still need to really deeply understand several git concepts to use it, GitKraken[0] is the best GUI tool I've used in daily practice. It integrates well with git hosts and has an attractive and mostly comprehensible interface. Accordingly, it isn't free (except for public repos). [0] https://gitkraken.com https://gitkraken.com