Git is software for manipulating graphs which, instead of drawing a graph you manipulate, makes you memorize a bunch of strings of magic words that map to certain transformations given certain graphs, try to imagine the current state of the graph, try to figure out which magic words will change the state you think it's in to a different state you want, try to imagine that state, then apply the transformation without seeing the result, and then type other magic words to try to figure out if
typing words transformed your
graph the way you thought.
Instead of showing you a graph and letting you change it.
It's mainly used by people who would say they're writing software, not manipulating graphs.
It also doesn't tell you this is happening, so people coming from another VCS don't even know there's this whole other part they should know. They memorize commands that seem to work, it goes ok, and then one day they ruin everything. Silly, that command means something different in the context you had no idea you were in. Duh.
Their experience with Git is that it's hard to make it work and then it randomly blows up. It's not because they're stupid or lazy. They're normal people dealing with a system that from their perspective is almost cartoonishly hostile.
They might wonder why they need to care about some underlying data model just to save their work instead of what they're doing now. If you have an answer that will make them want to switch, I suggest you spend a good while showing them pictures of history trees and ways you can change them. Name things slowly: this node is a "commit," this state change is a "reset," this transformation is a "rebase." If you have a workflow on top, draw more pictures of its states and changes using those terms. Then (re)introduce Git, a tool that does what you've shown them. Then set them up with a client where they have that flow with those terms and a graph they can look at, if not manipulate directly.