[skydhash]

> Ah yes, the hallmark of great software is having to learn how it's implemented to be able to use it.

Because learning how a software model a particular problem domain is a great step towards efficient use? You can hope it's magic, but that's a recipe for failure if you're a heavy user. Every professional learns the ins and outs of the tools he uses often.

[sunshowers]

When you are building a product or tool, it is very important to start with the vision of how users should interact with it first, and then figure out backwards how to achieve that vision. You don't have to treat it like magic, but learning how it works should be a bonus and not a requirement.

[metabagel]

https://v5.chriskrycho.com/essays/jj-init/

> The problems with Git are many, though. Most of all, its infamously terrible command line interface results in a terrible user experience. In my experience, very few working developers have a good mental model for Git. Instead, they have a handful of commands they have learned over the years: enough to get by, and little more. The common rejoinder is that developers ought to learn how Git works internally — that everything will make more sense that way.

This is nonsense. Git’s internals are interesting on an implementation level, but frankly add up to an incoherent mess in terms of a user mental model. This is a classic mistake for software developers, and one I have fallen prey to myself any number of times. I do not blame the Git developers for it, exactly. No one should have to understand the internals of the system to use it well, though; that is a simple failure of software design. Moreover, even those internals do not particularly cohere. The index, the number of things labeled “-ish” in the glossary, the way that a “detached HEAD” interacts with branches, the distinction between tags and branches, the important distinctions between commits, refs, and objects… It is not that any one of those things is bad in isolation, but as a set they do not amount to a mental model I can describe charitably. Put in programming language terms: One of the reasons the “surface syntax” of Git is so hard is that its semantics are a bit confused, and that inevitably shows up in the interface to users.

[nottoohard]

I truly don't get it. All these supposed software engineers who can't seem to grasp the basics of the tools of the trade. It's like watching carpenters argue about a hammer every few weeks for ten plus years.

There's no excuse. Either learn git, or stop using it. If you can do neither, stop complaining, because plenty of people use it just fine.

And no, you really don't have to understand the internals to use git, but you DO need a mental model of what's happening: what a commit is, what a ref is, what a branch is, what merging/rebasing does, etc. These don't involve knowing the internals, but they do involve maybe reading the manual and actually THINKING about what is happening.

Too many developers confuse not wanting to think about something with that thing being difficult. I learned git one summer during a college internship 15 years ago, and I've been fine ever since. I am really, truly, not that smart, and if I can do it, so can you.

Everyone needs to just quit their bitching and actually learn something for once.

[sunshowers]

I have many years of professional experience building source control systems. I almost certainly know more about Git's internals than you do.

Git exposes a great deal of unnecessary complexity. Any honest appraisal would recognize that.

Look at Jujutsu. That is a tool that is truly designed putting the user first, rather than just exposing the internals as the user interface and calling it a day.