The Terrible UX of Git (2021)
matt-rickard.com
matt-rickard.com
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.
> e.g. my colleague's `pr-to-pr.sh`
script
> [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
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?"
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.
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?
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), just 12 days after the first release of git on April 7, 2005 (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?
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).