Unfortunately whenever somebody asks what could a better option there are generally no answers except keep at it and you'll get used to it.
For me it's the other way round, git clicked way faster than other systems.
For example, say you’ve just made a commit, and then realized that wasn’t what you wanted to do so now you want to undo it. This can be described under git’s data model as “set the current branch to HEAD^ and discard the orphaned commit, leaving the working tree alone.” For some reason this is a “reset” operation (the same command you’d use to unstage a file, an otherwise unrelated operation) and you have to decide if you want to do a “hard,” “soft,” or “mixed” reset. If you get it wrong you’ll have to go grovelling in the reflog to get your files back.
To be fair, this situation is improving; the recent introduction of the switch and restore subcommands has helped to disentangle the especially overloaded checkout and reset subcommands, for example. But it’s still harder than it should be to convert a mental image of what you want done into the appropriate (series of) git commands, and vice versa.
1. There are great cheatsheets online that you can just print out and keep on your desk.
2. Write a user friendly cli wrapper on top of git (i think there might already some projects out there)
While I myself think I am pretty familiar with git cli, I don't really use the cli anymore, since intellij covers all the features in a much more intuitive way. e.g staged edits, rebase.
I'd also like to point out that the concept of not having the history local (as in CVS, SVN and some of the still-used commercial SCMs), but only on the special sanctified server, feels seriously weird and extremely limiting to me.
¹ The by far weirdest one is --set-upstream specifically (intentionally?) not working if local and remote branch names don't match, so "git push repository branchLocal:branchRemote -u" doesn't make "git push" work if you are on branchLocal. It feels like that's half the point to have that option in the first place. But nah.
Novice developers that just haven't taken the time to learn more than three basic git commands. Their lack of knowledge is the problem 99.9% of the time, but they don't know enough to know they are the limitation, and they blame the tool instead
Old developers that come with a mental model of another VCS and either cannot or will not change their mental model and continue to be frustrated that they weren't consulted when git was designed
A third category may exist, but I have not met these people IRL
Most notoriously, 'checkout' and 'reset' have a number of very different behaviours depending on the shape of the parameters you give them (which is why they've very recently added 'switch' and restore').
And some things that ought to be primitive operations don't seem to have any simple command at all. For example, if I have branch 'wip' checked out, and I'd like to advance branch 'dev' to point to the same thing as 'wip' without changing the currently checked-out files (even temporarily, because I don't want their timestamps to update).
And the preferred commands for managing the per-branch and per-remote push and fetch and merge settings have changed so often that I gave up years ago and just edit .git/config directly.
https://stackoverflow.com/questions/927358/how-do-i-undo-the...
If you want a coherent mental model of git, just do https://learngitbranching.js.org/ and never look back.
It's only very occasionally that I have to drop down to a command line to fix some kind of merging snafu - if that happens, I'm guaranteed to have to Google it, but at least I'm also guaranteed to easily find a solution on StackOverflow.
If we're talking about inconsistencies in git, the only one that comes to mind is how diff's `...` behaves like log's `..` and diff's `..` behaves like log's `...`. I.e. if you want to see the changes of `git log a..b` as a single diff, you'd use `git diff a...b`. If you want to see the changes of `git log a...b` as a single diff, you'd use `git diff a..b`.
https://steve-parker.org/articles/others/stephenson/holehawg...
But look at pictures from the maker. It's not a cube, and the handle is in fact ergonomic. Indeed, I would hope that a drill used by expert for hours every day would be 100% designed to make their jobs easier, and that includes not given them crippling injuries. And it's 100% purchasable from Home Depot. And, looking on Amazon, it's half the price of a truly expensive drill.
But there's another level at which the story is bad. The story feels like a story about gatekeeping: either you're one of the special people, or you're a useless homeowner. Either you have big problems, or you shouldn't be here. Either you've dedicated your life to drilling holes, or you're not welcome.
So, I read the story, and it sounds like both an exciting story of a newbie learning that some profession has unexpected depth. At the same time, it's also a story of a person who wants to be part of the special exclusive club.
- I have to be a good user of it. I can get away with knowing a couple flags for these tools
- Git is inherently stateful. I can iterate on my grep-ing/sed-ing/curl-ing and try random stuff, but git operation can be destructive or leave me in a state I don't understand and do not konw how to get out of
Note I think git could definitely be easier to use, and the reuse of eg checkout to switch branches and revert a dirty file to either staging or the most recent commit is a bit strange. But calling it uniquely bad is silly, imo obviously.
For working software engineers, I both think -- and recommend to juniors -- they must invest the effort to learn an editor, git, and at least one language + toolkit deeply.
As an example: when I buy a back-up hard drive from a typical brick store like Costco, the "back up hard drive" is abstracted away: I don't need to study the USB timing diagrams, or worry about the details of how the magnetic domains are imprinted on the spinning disks, or really any of the chemical details of the surface coating.
This abstracting away of details is AWESOME. I can buy a $150 disk drive after spending less than a minute considering the purchase.
Git, on the other hand...
Let me give a real-life example of where real-life git and real-life published work flows don't work: you can go into GitHub.com, and make a project. And you can write code in Visual Studio, and save it up to your new git project.
Unless, of course, when GitHub.com recommended that you add a license. The instant you add a license, the project isn't "empty", and once the project isn't "empty", you can't trivially push your new Visual Studio project up.
The fix for this is to delete your GitHub.com repo.
I bet you'll reply and say, "that's just real-world problem! I only want to hear about theoretical problems!" -- which, IMHO, is one of the problems my profession faces. Real-world problems are ignored in favor of theoretical ones.
The git commands do not abstract over the internals, they pretty much just provide a direct interface to them.
I don't really find that to be the case in normal use at all.
- Those who have never used Clearcase, Perforce, or any other enterprise monstrosity.
- Those who have and suffer from Stockholm syndrome.
Git offers the flexibility to let each person work the way they prefer, even (to a large extent) on large shared projects.
With some wrappers and hooks, you could quite easily cripple git so as to emulate most any simple VCS. The aforementioned enterprise products barely work at all, so replicating their non-functionality might require more effort.
Clearcase I agree was a POS.
