I think there are a number of great things to learn from the git UX.
- 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.
> 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?
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.
Good UX doesn't mean holding your hand. I think Vim has pretty great UX -- it's been my daily $EDITOR for years. Is there a steep learning curve? Sure.
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.
That's not why programs come with documentation. Documentation helps, but being intuitive in usage is something completely different. Intuitive means you can either do the simplest operations without reading the docs, or that you can figure it out as you go from the context clues. Git does neither. You need to learn about the model, the operations, the repo / staging / checkout / remote areas to complete the most trivial "modify-commit-push" workflow.
- 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.