[viraptor]

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

[xyzzy_plugh]

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.