[allover]

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.e. too much focus has been put on data structures and not enough on the rest of the tool.

A less efficient data structure, but more focus on UX could have saved millions of man hours by this point.

[gen220]

It's difficult, because git's exposition of it's data structures enables you to use it in ways that would not otherwise be possible.

I think git is more of a power-tool than people sometimes want it to be. It's more like vi than it is like MS Word, but it's ubiquity makes people wish it had an MS-word mode.

So, I think that it's hard to fault git's developers for where it is today. It's a faithful implementation of it's mission.

FWIW, I have never used a tool with better documentation than git in 2020 (it hasn't always had good --help documentation, but it absolutely does today).

[wtetzner]

Or perhaps learning Git just requires a different approach: you understand the model first, not the interface. Once you understand the model (which is quite simple), the interface is easy.

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