[dijksterhuis]

> I think yes, because git famously has a terrible UI, and any amount of telemetry would quickly tell you people fumble around a lot at first.

1. git doesn’t have a UI, it’s a program run in a terminal environment. the terminal is the interface for the user.

2. git has a specific design that was intended to solve a specific problem in a specific way. mostly for linux kernel development. so, the UX might seem terrible to you — but remember that it wasn’t built for you, nor was it designed for people in their first ever coding boot camp. that was never git’s purpose.

3. the fact that every other tool was designed so poorly that everyone (eventually, mostly) jumped on git as a new standard is an expression of the importance of designing systems well.

[Centigonal]

"UI" is a category that contains GUI as well as other UIs like TUIs and CLIs. "UX" encompasses a lot of design work that can be distilled into the UI, or into app design, or into documentation, or somewhere else.

[dijksterhuis]

> “UX" encompasses a lot of design work that can be distilled into the UI

like how git needs you to “commit” changes as if you’re committing a change to a row in a database table? thats a design/experience issue to me, not an “it has commands” issue.

[ForHackernews]

UI means "user interface". For a CLI tool the UI is the commands and modifiers it offers on the terminal.

[dijksterhuis]

i lump those into user experience (UX) stuff as it’s more leaning towards “flow of user action” etc.

[ulbu]

ok, you do, doesn’t mean that the difference others make of it are necessarily wrong, as the tone of your first comment suggested.

[dijksterhuis]

i believe that those people are wrong :shrug:

doesn’t change the bigger, more important fact that the struggles people have with git stem from the system design. i.e. the thing that ultimately determines what commands people need to run in what order (see points 2 and 3).

[Rapzid]

Yeah, UI impacts UX.

Also git has a UI.

[incrudible]

Mercurial was better than Git on almost any metric, it eludes me why it lost out to Git, perhaps because it lacked the kernel hacker aura, but also because it did not have a popular repository website with cute mascot going for it. Either way, tech history is full of examples of better designs not winning minds, due to cost, market timing, etc. And now with LLMs being trained on whatever was popular three years ago, we may be stuck with it forever.

[gavinhoward]

Because Git was faster.

This mattered because speed is the killer feature [1], and speed is often seen by users as a proxy for reliability [2].

[1]: https://bdickason.com/posts/speed-is-the-killer-feature/

[2]: https://craigmod.com/essays/fast_software/

[JoshTriplett]

> Mercurial was better than Git on almost any metric, it eludes me why it lost out to Git

I used Mercurial, professionally, back when there were a half-dozen serious VCS contenders, to contribute to projects that used it. I disliked it and found it unintuitive. I liked Git much better. Tastes vary.

Git made me feel like I was in control. Mercurial didn't.

Mercurial's handling of branches was focused on "one branch, one working directory", and made it hard to manage many branches within one working directory.

Mercurial's handling of branches also made it really painful to just have an arbitrary number of local experimental branches that I didn't immediately want to merge upstream. "Welcome to Mercurial, how can I merge your heads right now, you wanted to do that right now, right?"

Git's model of "a branch is just a pointer to a commit, commits internally have no idea what branch they're on" felt intuitive and comfortable.