[rabidrat]

People keep repeating this, but it's not true. The interface has so many "this flag in this case" but "this other flag in that case" and "that command doesn't support this flag like that" etc. There's no composability or orthoganality or suggestiveness. It's nonsensical and capricious and unmemorable, even though I understand the "simple" underlying model and have for years.

[wtetzner]

Sorry, I was replying to this:

> The counter argument would be that git is the poster-child of poor UX, which could be blamed on the fact that it exposes too much of its internal data structure and general inner-workings to the user.

I agree with you that the UI is inconsistent, however I don't agree that it's the result of git exposing too much of the internal data structure.

[triangleman]

Has anyone attempted to re-engineer a superior UX on top of the git data structure? Would it even be possible?

[rabidrat]

Yes, I think so. There are many git clients which offer superior UX already, but they only provide a subset of the functionality available with the data structure. I'd personally love to experiment with showing and editing the data structure more 'directly', instead of relying on a battery of CLI commands and options.

[codemonkey-zeta]

Magit with emacs solves git's UX problem IMO. Discoverability is/was git's real problem.

[disgruntledphd2]

This is true, but the trouble is that you need to know what git will do before the magit commands and options make sense.