The git plumbing and plumbing commands are straightforward and easy enough to understand once you read about them a bit (I recommend the free Pro Git book online).
The original git porcelain commands - git branch, git reset, git pull - are execrable. They’re filled with implementation details (index/cache vs staging), weird and suggestive syntax that seems like it should be extensible and widely applicable but isn’t (localbranch:remotebranch), and nuclear-powered self-destruct functionality hidden amongst playthings (git reset vs git reset —hard).
It sounds like git in general isn't necessarily the problem (at least after getting the basic model down), it's specifically the interface and associated foot-guns it sticks in there for beginners (and tired experts) to trip over.
Most people most of the time will get by if they grab a decent git GUI, figure out the minimal set of operations they need, and just Google the rest when necessary.
My stupidest git mistake was when I was cleaning out a directory of bin and obj folders and included gits obj folder as well. And of course after crying in the corner for a bit I take a little time to look into git commands and I could have just run 'git clean'
Pull defaulting to rebase could be a dangerous and chaotic default. If you want to argue that pulling should be fast-forward-only, then I'd say maybe you have a case.
I have aliases ff for fast-forward-only merges and puff for fast-forward-only pulls. I never type `git pull` anymore, and it's much harder to shoot your foot off with the aliases.
Yeah, something along these lines is how I've explained it to co-workers as well. Tossing in "git log --all --oneline --decorate --graph" so they can actually see the graph also helps a lot.
is even better. Most people don't work in front of VT100s today.
Actually I work most of the day remotely in `screen` on my office machine. But in case of complicated/confusing/buggy history/branching I fetch for the repo so I can run gitk locally.
Because that's exactly what it is, and it's not. When I explain git to newbies in this way, it's like something clicks in their brain and they just start to "get it" as well.
But then once you get the mental model you spend the other 90% of the time figuring out what magic incantations are needed to transform the graph in the way you want.
The sad thing is you can't just "figure it out." Most folks do "good-enough" after some coaching and memorizing a limited set of commands needed for their workflow-- until something unexpected happens.
It could be a typo, or trying something new, or forgetting/misunderstanding the intent of some counterintuitive command, or maybe cleaning up an existing problem. All those things can easily put someone in a deep rabbit hole of inside git book or, worse, google search.
Well it's understandable. Moving nodes in a graph (a tree, really) has a lot of side effects. Couple that with multiple people trying to keep things in sync(ish) and it gets super complex.
It could be hard if you never took Discrete or another course that introduces graph theory. Or if you cheated your way through or barely scraped by. I can see how a CS freshman or someone from another field might struggle, but even then it's more comprehensible than any of the alternatives.
I think that's a fine perspective for a computer scientist or graph theorist, myself. Fortunately, since the article title is "Git for Computer Scientists," that's essentially the approach the article takes. :-)
The 'complex' part usually relates to how to manage the graph in terms of what you want to do, and all the odd states that might exist otherwise, especially when syncing with 'other graphs'.
I had no idea why it took my brain so long to wrap my head around it. Maybe it was blissful ignorance, never sitting down and making a mental model of it. Always looking for a tldr version of doing things. I don't know exactly at which point things clicked but it went from bewildering to just makes sense
The original git porcelain commands - git branch, git reset, git pull - are execrable. They’re filled with implementation details (index/cache vs staging), weird and suggestive syntax that seems like it should be extensible and widely applicable but isn’t (localbranch:remotebranch), and nuclear-powered self-destruct functionality hidden amongst playthings (git reset vs git reset —hard).