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.
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.
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.
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...
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.
https://old.reddit.com/r/todayilearned/comments/158lp0m/comm...
>My high school shop teacher, before he let any of us near the machines or power tools, told us horror stories about students who lost fingers and eyes by being careless with them. For the entirety of that semester, nobody got so much as a chipped fingernail.
which is a better match for my experience --- the best advice I ever got was from my high school shop teacher:
>Before turning on the power switch, count to ten under your breath on all your fingers while visualizing all the forces involved and all the ways the operation could go wrong, then remind yourself that you want to be able to repeat that count after turning the power off.
I don't think Sawstop would have a business model if all tablesaw injuries were tried by a jury of such shop teachers (heard him scream at the kid who removed a guard through hearing protection all the way on the other side of the shop around a corner while operating a lathe while making a heavy interrupted roughing cut w/ a chisel I really should have paused to sharpen --- the student was banned from ever entering the shop again).
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.
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.
I've read a few blog posts and half a book on git, and I don't remember the last time I had issues with it.
I also don't recall a junior ever having trouble uploading files with git. Unless they're in an interactive rebase, which wouldn't happen your first time trying out git.
Git is just a means to an end. Heck, it’s usually a means to a means to an end: it is only a tool for version control of code, and the code itself is just a means to education or running the actual business.
There are wrappers that make it much more approachable. IntelliJ’s Git frontend, for example, is pretty nice.
git-log --graph --reflog
git-commit --amend
git-cherry-pick
With the above in order, I found I could subset the git state model:
* temporary branches rather than the "stash"
* commit tentative work to HEAD; amend, discard or set aside in a temporary branches rather than as later discoveries require
* side-step the index/cache/staging_area for most operations -- transfer directly between work tree and HEAD commit
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
For professional work, people can and do learn complex interfaces and jargon, if it is advantageous.
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.
Does "getting it done with pliers" make them a good wrench?
Now, until such a person exists, ridiculous counterexamples are still ridiculous.
A compromise/synthesis: everyone should absolutely learn how git works internally, but not necessarily how to use the git-specific porcelain/tooling/CLI
Fast forward twelve years and my wife did the MCIT at UPenn (https://catalog.upenn.edu/graduate/programs/computer-informa...) where git and other topics woven into the curriculum. Even then, they were perhaps a novelty because their focus was bringing non-CS undergrads into a CS Masters program. So-called "conversion" master's degrees were the norm in the UK in 2002.
I think this is a good argument for teaching git, and being thorough in doing so, as many people are likely to never take that initiative themselves, while the benefits to being good at git are so obvious.
I'm sure there's an element of (intellectual) laziness too, but I think people tend to only learn git by necessity because git is simply unpleasant to use.
A lot of us have Stockholm syndrome because git is less bad than what came before it, but git is not good.
Like, I attempt to write good commit messages and stage my changes in such a way that the commits are small, obvious, and understandable. That's about it. But the advanced tooling around git is scary ngl.
Meanwhile enterprise teams are often like - who cares, let's auto-squash all commits into one.
This is just false. In the UK, you would learn version control in the first week, then submit all work through version control for the whole course.
I find it hard to believe that Americans just don't use version control at school. It doesn't make any sense.
There are cases where I've staged commits this way for a PR, to make it more reviewable. I'd usually rather split them off into separate PRs, but when that would create a pipeline of three MRs that are meaningless on their own, then rewriting history for a single MR makes sense. I generally consider my feature branch's commit history to be for me, not for you. Going back and rewriting history is a chore that shouldn't be necessary if I did a decent enough job with the PR description and task decomposition. Those commits are getting squashed anyway. Along with all the "fix MR comments" commits on top of it.
It wouldn't bother me to adopt your workflow if it fits your team and its tools and processes. I'd just say, consider that your way isn't the only correct way of doing things. Your preferences are valid, but so are others'. The only thing that really bothers me is absolutism. "My way or the highway."
Your writing here reminded me of a particularly unpleasant coworker I had in the past. I quickly browsed your comment history to make sure you're not him... Excessive rigidity is not an endearing quality.
All that being said, I have also been constantly annoyed by people with too many YoE who can't be bothered to spend an hour or three to learn the basics of how the Git tree is structured, and what merge vs rebase does. They rely too heavily on their GUI crutches and can't fix anything once it goes sideways. Even when you lead them to water, sending them reading material and offering to answer questions after, they refuse to drink. Willful ignorance is far more irritating than stubbornness. I don't expect them to be able to remember what bisect vs cherry-pick does. Claude will spit out the subcommands for them if they can describe what they need in English. But they can't do that if they have no understanding of the underlying data structures...