git
- sub commands (and sub sub commands) provide a high level abstraction over the many different tools and features. The "toolkit" approach allows for easy expansion and refactoring of individual features, and is entirely pluggable by end users. It even provides tools to interface seamlessly (git rev-parse --parseopt; rev-parse is amazing and allows you to wrangle git types trivially). Git also doesn't care what language you use. It ships git subcommands in C, shell and perl, but you can use node, python, bash, go, whatever you like. Really great.
- git divides it's interface and features into porcelain (user facing) and plumbing (internal; used by porcelain implementations). This allows them to avoid breaking changes while providing new and exciting features. This is a great design choice and it's been copied extensively by many projects, but I've never seen it pulled off as well as git.
- git consistently reuses terms and objects (there have been some missteps over the years but the maintainers are very humble). Commit objects, refs, dates and times all work the same almost everywhere.
- git is extremely well documented, both in its man pages, online and within the tool itself. Help flags and interactive messages and descriptions and suggestions of what to do next. Have you ever performed an interactive rebase? Or resolved a merge commit? Or corrected a tracking branch? Just great stuff.
I know we love to hate on git here but let's just for a moment acknowledge this wonderful, powerful tool for something it does a great job at. Git cuts no corners, it's consistent and trustworthy, and a hallmark of modern day software engineering and UX.
Yes to all. Then I showed it to people new to git. And saw them fail week after week. They got into states they didn't expect, didn't understand, and didn't see expected feedback. Clever people who needed to blow away the repo to get to a known state in the easiest way. The most common problem was making a new commit in the middle of a rebase, and accidental committing or blowing away conflicts on pull. Next was switching the branch during an interactive operation and basically ending up with unknown state.
You listed many things which make git powerful, but a good ux is something different. It requires good, consistent context, clear boundaries between expected and unexpected operations (why can you checkout during rebase, for example?), and discoverability. If you interact with enough developers, you'll get asked "what do I do? I don't know what just happened" - and that's the mark of bad ux.
Often with tools like Vim, Git, etc. there is a dependency on the end user taking the time to learn, absorb and understand the documentation for the tool.
> It requires good, consistent context, clear boundaries between expected and unexpected operations (why can you checkout during rebase, for example?), and discoverability.
I think git really excels here. Why wouldn't you want to be able to checkout during a rebase?
To me, UX is ultimately about the long tail -- if I am using this tool for a hundred hours a week, am I helped or hindered by it? For too many tools society embraces, it's the latter.
UX and HCI is about so much more than just sitting an untrained person in front of a keyboard.
Git as a command will not help you.
But git's user interface is inconsistent, has got weird error messages and confusing terminology with too many ways to do some things.
Good thing that it has quite decent manpages which explain these things thoroughly. The UI gets the job done but it sure isn't a great example of a well designed command line.
There are other projects that interact with git and are really good: tig, for example. But git itself? Someone wrote a good paper about it already. "What's wrong with git?" was the title, I believe.
That said, you are right that understanding the git model helps a lot and for that, I recommend the "Getting Git" talk. https://vimeo.com/14629850
Git was made by and made for kernel hackers to support the Linux kernel. It has an expectation that the user understands how their computer works and wants a tool catered to that knowledge. The average web developer writing Ruby or Node in Atom on their Macbook Pro isn't in the target audienece. For someone in git's target audienece, it's a great tool with far better UX than any other VCS - because it gets out of your way and gives you powerful tools for mucking with the VCS to suit your needs precisely. THIS is what makes for a good UX. A tool that's easy to learn is great, but if it can't be mastered and bent to the user's will then I'd rather take one that's hard to learn but accomodating of the master.
It does not matter who it was designed for, git is the de-facto VCS that almost everyone uses today. And people are having trouble using it because there is no better alternative: it is fast and powerful and used by many companies.
But it's UX is terrible: I use git for 10 years and I have to Google every time I need to make a branch tracking a remote one. git reset does different things based on what type of object you pass.
This has nothing to do with knowing how internals work, it is a question of consistency and providing a small non-overlapping set of tools to do my job.
It _does_ matter who it's designed for. If someone outside the target audience uses it, then it's not the tools fault for not accomodating them. My point is that the UX is great for those it's meant to be great for.
>I use git for 10 years and I have to Google every time I need to make a branch tracking a remote one.
git branch --set-upstream-to=upstream/master master
Didn't have to look this up. Seems pretty straightforward. Or just git push -u upstream master.
>git reset does different things based on what type of object you pass.
So? I don't see how this is a bad UX. Would you prefer 10 different commands? I wouldn't.
Can't quite put my finger on it, but some subtle differences seem to nudge the user towards more usable workflows than bare git.
(I mean when it's not an unpredictable sequence of commands that need to be passed to accomplish something outside of a regular workflow)
Probably the cli that I find the most useful beyond git that I use regularly is docker... It's pretty useful if you aren't in a linux environment but need to build something in one... In my node lambda builds, I'll do something like:
docker -i -v "${PWD}/dist":/app -w /app node:6.10 npm i