[xml]

If most people are not using a tool properly, it is not their fault; it is the tool's fault.

Git is better than what came before, and it might be the best at what it does, but that does not mean that it is good.

- The interface is unintuitive.

- Jargon is everywhere.

- Feature discoverability is bad.

- Once something goes wrong, it is often more difficult to recover. If you're not familiar enough with Git to get yourself into that situation, then you certainly aren't familiar enough to get yourself out of it.

Many of those issues are due to git being a command line interface, but others (like no general undo and funny names) are simply due to bad design.

I think it is about time that we try again and build a better version control tool, but maybe git is just too entrenched.

[shagie]

> If most people are not using a tool properly, it is not their fault; it is the tool's fault.

I would say that is a reasonable criticism of git ... but I've seen the same thing in svn, perforce, cvs, and rcs. Different variations of the same issue of people not caring about the version history.

Since it's been a problem since the dawn of version control, it is either something that is part of all version control being a tool's fault that has been carried with it since doing ci, or it is something that people aren't caring about.

I feel this is more akin to a lack of comments in code and poor style choices and blaming the text editor for not making it easier to comment code.

[zer00eyz]

> problem since the dawn of version control ... a tool's fault ... or it is something that people aren't caring about.

At the start of my career I ended up in a UI position. Old school usability on the back side of a 2 way mirror.

The tool has lots of shortcomings: images, documents that aren't text, working with parts of repositories... These aren't issues faced by the kernel (where emailing patches is the order of the day). And these shortcomings have lead to other tools emerging and being popular, like artifactory, journaling file systems, and various DAM's.

Technology on the whole keeps stacking turtles rather than going back to first principles and fixing core issues. Auth (DAP, LDAP, and every modern auth solution). Security (so many layers, tied back to auth). Containers and virtualization (as a means of installing software...). Versioning is just one among this number. We keep stacking turtles in the hope that another layer of abstraction will solve the problem, but we're just hiding it.

One of the few places where we (as an industry) have gone back and "ripped off the bandaid" is Systemd... It's a vast improvement but I would not call it user friendly.

Usability remains a red headed step child, its the last bastion of "wont fix: works for me" being an acceptable answer.

[cameronh90]

> If most people are not using a tool properly, it is not their fault; it is the tool's fault.

This is a standard that we don't apply to most other tools outside of IT. I do think git could be more usable, but most powerful tools have sharp edges and require training.

A bandsaw is a fantastic tool, but if you try to use one without reading about it first, you'll end up losing a finger. I'm not sure I'd blame the bandsaw in that instance...

[dpc050505]

Contemporary bandsaws used by people who take workplace safety seriously have emergency brakes for just that reason (countless trained operators also lost fingers). Improving tools is something we've been doing since our ancestors first held a branch. If we satisfied ourselves with good enough we'd live much different lives.

[fragmede]

Then again, the number of shop teachers missing a finger would give anybody pause. Blame is secondary to the fact that you just lost your fucking finger. Thankfully, git's sharp edges won't permanently physically maim you, though guts sharp edges resulting in you committing API keys GitHub can still hurt you, just in your wallet but at least you didn't lose a finger.

[xml]

To put it into your metaphor: I am not advocating against the existence of bandsaws. I would just rather have bandsaws that do not cut off your fingers if you do not read a book about them first and make it difficult to sew the fingers back on, while requiring arcane incantations to do their work.

There are of course power tools with obnoxious protections that make them difficult to use, but since we are dealing with software here, we are not bound by the laws of physics. I believe that we can create a better tool that is both powerful and easy to use.

[netdevphoenix]

> If most people are not using a tool properly, it is not their fault; it is the tool's fault.

Replace tool with one of piano|guitar|etc and see your logic fall apart. Software tools like any other have a manual and require effort and time to learn.

[Throaway1982]

modern instruments are actually improved designs of older instruments which were just that: badly-designed & hard to use

[1718627440]

The hardest thing to get people to, is to think of a evolution of their codebase as opposed to just a single state with a sophisticated backup system. Writing proper commit messages and diffs follows from that. The actual Git commands are then incidentally.

[tech_tuna]

Git is better in some ways, but it is insanely complicated. That matters less now with AI tooling but still there was a time when we all had many choices (commercial and open source) for source control tools. My canonical example is git checkout -b <branch_name> for a new branch, git branch -D <branch_name> to delete the local branch and git push origin :<branch_name>.

I know that that is the old syntax but holy hell, that's insane. Why couldn't it always have been git branch --create|delete|delete-remote? It could have but Linus doesn't care about your feelings or small brain. :)

[janalsncm]

Git has poor design because it forces users to learn its model of things rather than meeting users where they are. There’s way too many leaky abstractions that pop out as soon as you stray from the happy path, and you might not even know you’re straying when you do it.

Instead, the complexity of your mental model should scale with the complexity of the thing you’re trying to do. Writing a “hello world” in Java does not require a mental model of all of the powerful things Java can do.

We want CS 101 students to use version control but for a lot of them it will also be their first time using a CLI and a programming and also the underlying CS concept.

[Hendrikto]

> Git has poor design because it forces users to learn its model of things rather than meeting users where they are.

If the users are unwilling to put even a minimum of effort and thought into it, that is pretty much impossible. I see that as the main problem.

[owlstuffing]

Right on. Git is good at what it does, but its CLI is too low-level. It feels more like an assembly language than an end-user language, and a haphazard one at that.

There are wrappers that make it much more approachable. IntelliJ’s Git frontend, for example, is pretty nice.

[skydhash]

Git is a cli software. If you find yourself repeating a set of commands, what you should do is abstract it using an alias or a script. And you will have you own nice interface.

[Noumenon72]

IntelliJ's Git frontend makes the Git command line look like a relic for people who would rather type "outlook forward email" than use a GUI. I was disappointed they gave up their attempt to make it a standalone app.

[intended]

For UI/UX arguments on professional grade software, I present the Bloomberg terminal. A fever dream in shades of orange, black and blue.

For professional work, people can and do learn complex interfaces and jargon, if it is advantageous.

[krupan]

Very true, though it has improved a over the years. Most people haven't noticed because when git has introduced newer simpler commands it hasn't deprecated the old ones. You can now use it like this, but most people don't know it:

git switch some-branch # edit files git restore file2 # undo changes to file2 git stage file1 git commit

Instead of the old workflow using checkout with a bunch of different flags.

I agree though that git is needlessly obtuse. I advocated for mercurial instead of git for years because mercurial was so much more user friendly, but git won. I hear good things about jj now

[jimbokun]

I haven’t used jj but isn’t that exactly what it’s meant to be?

I believe git is architecturally sound and well designed, but the command line syntax can be overly confusing and opaque.

[marcosdumay]

Git is badly designed, but your rule is also bad.

If somebody can get a lot done with a tool, then it's a good tool. And a lot of tools can't both enable people to get things done and avoid being misused. They have to pick one.

[owlstuffing]

> If somebody can get a lot done with a tool, then it's a good tool.

Does "getting it done with pliers" make them a good wrench?