When I was early in my career, I always thought that Git is hard and nerdy, and it is a good thing. I kinda liked it in a way, like there is some gratification in knowing all the commands and helping clueless coworkers, or knowing how to do a rebase -i and shuffle commits around and show off etc.
These days, I find myself just using the smallest subset of commands possible to do my job, and it is enough. Just add, commit, push/pull and occasional stash or merge is like 99.9% of my daily usage. I don't even remember how to revert (was it checkout -- <filename> or reset <filename> or restore <filename>?) and I'm just fine with it.
I think that git is easy. Just learn the happy path, and maybe a way or two for restoring to a known good state without deleting the whole repo, it's enough.
This is a textbook example of damning with faint praise. If your VCS's interface is so bad that it motivates you to scale back your use of any nontrivial version-control features and instead just content yourself with rudimentary file syncing, that's a case against the interface. Either the additional features are useful and you're missing out on that benefit, or they're extraneous and are saddling the tool with unnecessary baggage.
Or, hear me out, the tool has enough features to cover a wider range of use cases than your own. You're not missing the benefit of features outside your use cases.
I believe it was git that finally made me accept that my working memory is actually below average and that I’ve coped basically my entire life by leaning on my chimpanzee-like spatial reasoning and building mind [palace] for everything, especially architectural and network topology conversations (I became the reviewer and copy-editor for the network architect for a project I wasn’t even on because someone knew me better than I did). Graph theory works a treat with this so I become the de facto VCS surgeon. It’s “just” a big, fat, straggly, 4 dimensional tree.
I try not to torture anyone with it (VCS repair) who hasn’t already exhibited a knack for graph theory. I just tell them where the man traps are and to ask if they feel like they need to go there.
I agree people should at least learn the happy path. It really is not hard at all and it solidifies the underlying concepts.
However I find there is a huge difference between me working solo on a repo or with one or two other people versus managing a complex project with 10+ developers and multiple SKUs in the same codebase (as an example).
That's when the "neurosurgery" aspects come in. Problems were frequently caused by junior devs making mistakes in their repo management that could be a headache to untangle (again, as an example).
I agree, but partly for that reason I use fossil for most of my hobby projects. It is less stressful to not have so many features outside of the ones I use, and to not even have to be tempted to rebase or otherwise rewrite history as that is not supported.
For work and all my older hobby projects still only use git and I used that for ages and know it quite well, but that does not mean I always feel like I need to use it instead of something simpler.
(It is also FUN to use some other tool and not just git year after year. Got to learn something new now and then.)
These days, I find myself just using the smallest subset of commands possible to do my job, and it is enough. Just add, commit, push/pull and occasional stash or merge is like 99.9% of my daily usage. I don't even remember how to revert (was it checkout -- <filename> or reset <filename> or restore <filename>?) and I'm just fine with it.
I think that git is easy. Just learn the happy path, and maybe a way or two for restoring to a known good state without deleting the whole repo, it's enough.