Curious question: why do you think git sucks? From my perspective is one of the fundamental tools behind modern software engineering. brilliantly designed and yet so simple to use. I’ll even go ahead of myself to believe you’d be able to make a successful tech company just providing a “git for X” where X is another industry
Of the DVCS systems that came out at around the same time (hg, git, and bzr all came out within a month or two of each other), I would probably rate git the worst.
The most notable issue with git is that it's help is... anti-helpful. It is pretty jargon-filled, and there have been numerous moments where reading a help page has left me actively more confused about what a git command is doing.
Of course, part of the reason why the help is so unhelpful is because git's UX is poorly designed. When even the help page has to admit that a command actually does three different things depending on parameters, you know it's bad.
I'll also point out that I've seen far more repository corruption issues with git than I have with any other VCS (and I've used CVS). Accidentally torching your data is quite easy in git, and appreciate the irony of an immutable store of data needing a garbage collector for the data it's storing. Something like Mercurial's changeset evolution and phases is far, far saner for development than working with branches in git.
Mostly the UX is inconsistent. Git Koans [0], which is now 10 years old, still holds mostly true. I do feel it has improved, though not in ways I've bothered to use. `git switch` for example, was introduced at, uh, some point because `checkout` is so overloaded.
Anyway, git was the first and only VCS I ever learned so I don't really see the big deal myself. I didn't learn all the internals super well, but I generally did just learned it. On the same token I've never really heard of a VCS that people don't complain about. Except Mercurial.
DX is awful. Inconsistent, unnecessarily confusing, obvious and common usability paths aren't straightforward. The simpliest example: why isn't "git undo" a thing?
> From my perspective is one of the fundamental tools behind modern software engineering.
This dogmatism is the root cause behind the lack of improvement. People insist it's already good enough.
> yet so simple to use.
Simple until it's not, which is almost immediately.
> I’ll even go ahead of myself to believe you’d be able to make a successful tech company just providing a “git for X” where X is another industry
Few other industries would be so convoluted into thinking such a terrible user experience would be allowable.
For me it’s the fact that everything about it seems to be about making the tool easier for the developers who wrote it to write it rather than making it easier for the people actually using it. It periodically tells me that garbage collection has given up and I need to run a specific git command to make it work again. Why doesn’t it just run it since it knows the command? Also, as a user, is there any benefit to me knowing that garbage collection happens at all? I’ve never had to know or care about that with any other source control tool. Either it didn’t exist, or it worked so well that it never came up.
There’s a bunch of modal-ness (modality?) throughout git. You can’t be explicit about things so it’s extremely easy to make a mistake. I’ve frequently gone to make a branch only to realize I had the wrong parent checked out, so now my branch is branched off the wrong thing. In other systems I could say “<tool name> create branch x from parent y”. In fact, this has happened so frequently in our group at work, that several reminders have gone out to “make sure you branch off the correct branch…”
It handles large files really poorly and requires a 3rd party tool to make it work reasonably. But then if you use lfs or a similar tool, several other 3rd party tools that work with git don’t work.
> In other systems I could say “<tool name> create branch x from parent y”.
While the default of `git branch` is to branch from the commit you have checked out, the command does take an optional argument for the start point of the new branch:
The general complaint is that Git's UI requires you to understand how it works internally to be able to use it (properly).
IMHO Git is fine, and forcing the complexity on the user is not a big deal as Git is simple enough... as long as you forget that submodules ever existed. Git's approach really shows it's problems when you use submodules:
- Want to clone a repo with submodules? Gotta know beforehand to use git clone --recursive, or remember to use git submodule update --init --recursive after cloning.
- Want to pull? Now you have to use git pull --recurse-submodules instead of git pull.
- Want to checkout a branch? Now you have to remember to do git submodule update --recursive after checking it out.
Etcetera. Instead of being handled transparently by Git like they should be now every time you do something in Git you have to remember to do something else to babysit the submodules.
It's complicated to the point that a lot of people come up with their own alternative instead of using submodules (git subtree, git subrepo, etc)
