Hacker News Reader

Comment by umvi | Hacker News Reader

I just think of git as a graph and branches/tags as text pointers to nodes in the graph. Doesn't seem that complex to me...

Maybe I "got gud" though and can no longer empathize with git beginners

View on HN

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

`git checkout` great for switching to a different commit and for throwing away local unstaged changes!

Using `git checkout` with a filename really really really should have a yes/no prompt by default, or at least an `-i` option like `rm`.

I think `git switch` is an attempt to resolve this

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'

Two additional bad defaults: crlf handling on Windows, and pull not defaulting to rebase.

The message "up to date with origin/master" is also misleading, because it doesn't check the remote itself.

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.

    gitk --all

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.

Especially if they took a maths course on graph theory.

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.

90% of the time you can achieve what you want with `git rebase -i`

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.

The hard part of git has never been the understanding its graph model.

The hard part HAS ALWAYS BEEN is memorizing all those badly named and counterintuitive commands.

Even that is only true if you're coming from a system where branch, tag, and checkout mean something else.

I think the hard part of Git isn't the bit you've just described. It's the terrible CLI and terminology.

Give any Git newbie a decent GUI and a translation for Git terminology into sane terminology and they will have no problems.

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

That's pretty much the gist of the article, no?

That's what makes it good :)

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

I think all that is needed is an aha moment

i honestly feel people are allergic to rtfm

Reply on news.ycombinator.com