I don't champion git, but it is sort of the least worst SCM overall. I'm a graph thinker so that aspect never gave me much trouble, but the CLI is a seriously weird jungle of odd naming, based limitations¹, do-all commands with flags changing the entire command out for a different one and poorly written manpages.

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.

I've never had problems with git "not mapping" to my mental model of what I'm doing, so maybe you could help expand on what that means. But I've run into two categories of people that struggle with git

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

My use case is simple enough. Git provides a list of checkpoints I can rollback to. I generally squash over merge, and I use vimdiff to resolve conflicts. I know every command I need to do those things. What's complicated to learn?

If you want a coherent mental model of git, just do https://learngitbranching.js.org/ and never look back.

For 99% of git, I'm happy with GUI tooling in the likes of VS Code, Visual Studio and Rider - it's clear, and it works great.

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.

I've never felt that the commands don't make sense or that they don't map to my mental model. Actually I don't understand that complaint. It's not like I set a mental model prior to learning git and expect git to follow it. I base my mental model on git while learning it, so of course it's going to map it. That's what learning how to use a software entails.

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`.

Git, like UNIX is a Hole Hawg.

https://steve-parker.org/articles/others/stephenson/holehawg...

What makes git different than other cli tools like grep, sed, curl, etc?

I just use a decent GUI with all the use cases I need: SmartGit does it for me. Totally recommend

It maps very well to my own mental model? I'm not arguing that the parent poster doesn't have the problem that they say they have, but it's a problem I do not have and haven't encountered very much with new users after explaining it to them?

git gud

I assume that people who find git extremely difficult are unwilling or incapable of learning the internal data model. I think if you want to have distributed source control, there is a minimal complexity that exists. I also previously used cvs, svn, and perforce, so maybe that affects my opinions; I strongly believe git is a huge improvement over all of the aforementioned.

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.

Git has a very clean and simple data model. Unfortunately, this nice model often has very little bearing on how the `git` CLI works; it often takes things that should be simple operations and confuses or complicates them in various ways.

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.

The philosophy of git is fantastic, it is its unending collection of quirks, footguns, and inconsistencies that irritate people.

Because other things are worse git can't have problems?

Perforce is fantastic and I'll take it over git any day.

Clearcase I agree was a POS.

Do you have any regrets with sticking with mercurial instead of hopping on the git bandwagon?

SVN is so dead simple to learn and use. And while I see the benefit of DVCS it hasn't really had much impact on developer productivity. The tools around are just so much more sophisticated than what we had for SVN. And I kinda miss being able to checkout subfolders directly.