git gets easier once you get the basic idea that branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space.
(source)
Edit: but to actually have content in this comment, I’m not sure the mental model is the problem. It’s not that alien that a good explanation wouldn’t help, but it took a long time for git to start paying any sort of attention to “human readability.” It was and still is in a way “aggressively technical” and often felt like it purposefully wanted to keep anybody but the most UNIX-bearded kernel hackers from using it. The man pages were rarely helpful unless you already understood git, the options were very unintuitively named, etc etc. And considering Linus’ personality, I’m not exactly surprised.
With a little bit of more thought on how to make it more usable right from the start, I’m not sure it’d have such a reputation as it has now. The reason why I think this endofunctor joke is so funny is that that sort of explanation to “simplify” git wouldn’t have been at all out of place – followed by the UNIX beards scoffing at the poor lusers who didn’t understand their obviously clear description of what git branches are.
Personally it was when I was trying to commit and I got stuck in an authentication loop of git asking for my username or email (even used --global) and it would not work or remember no matter what I tried (was recommended to reinstall mint, yeah no lmao not again).
Ended up installing the unofficial GUI and I’m MUCH happier but I tell ya if you bork something in Mint it’s really hard to fix it if your not a CLI wizard.
Git GUI wise I can do all the basic stuff I need and if something breaks than I use the CLI because there’s more documentation on it
In this thread - tons of smart people thinking that the tools we use to replace “make a backup of a file on a server somewhere” should require entire reference books, as if that’s normal.
Saying “it’s a graph of commits” makes no sense to a layperson. Hell the word “diff” makes no sense. Requiring training to get something right is acceptable, but “using CVS” is a tiny tiny part of the job, not the whole job. I mean, even most of the commenters on this thread are getting small things wrong (and some are handwaving it away saying “oh that small detail doesn’t matter”).
Look, git is hard. It’s learnable, but it’s hard. The concepts are medium hard to understand, and the way it does things is unique and designed for distributed, asynchronous work - which are usually hard problems to solve.
Saying “it’s a graph of commits” makes no sense to a layperson.
Sure, but git is aimed at programmers. Who should have learned graph theory in university. It was past of the very first course I had as an undergraduate many years ago.
Git is definitely hard though for almost all the reasons in the article, perhaps other reasons too. But not understanding what a DAG is shouldn’t be one of them, for the intended target audience.
While I agree 100% with your main point,
"it’s a graph of commits” makes no sense to a layperson
You’re probably putting your standards too low. Every coder should know what a graph is, the basic concept at least. If you can understand fizzbuzz you can understand graphs too.
the word “diff” makes no sense
diff is short for difference. And that basically explains it
I honestly don’t get why folks dislike rebase. I use it constantly, especially to squash commits so that my pull requests are a single commit that can be reverted easily.
I use rebase when I’m working in a dev branch. If someone else has pushed changes to the main branch, rebasing the dev branch on top of main is a way to do the hard work of resolving merge conflicts up front. Then I can rerun tests and make sure everything still works with changes from the main branch. And finally, when it is time to merge my dev branch to main, it’s a simple fast-forward.
Because rebase is fraught with peril, if you also push rebased branches upstream and someone else works off that branch.
If you stick to the rule of only using rebase on local branches that have never been pushed upstream, it’s an awesome tool. If you don’t, you’re eventually going to cause someone to have a bad day.
Yeah, basically anything that rewrites already pushed history and is then (force-) push is bound to create problems (unless it’s a solo dev only ever coding on a single device, who uses the remote repo as a mere backup solution).
It’s also kinda annoying to have a history full of “merge” commits polluting the commit messages and an entwined mix of parallel branches crossing each other at every merge all over the timeline. Rebasing makes things so much cleaner, keeping the branches separate until a proper merge is needed once the branch is ready.
