Comment by lexicality | Hacker News Reader

Comment by lexicality | Hacker News Reader

In my experience doing mentorship, a lot of people are taught git in a super rushed way and tend to have the mindset of "here's this incredibly complicated program you will never understand, please learn these magic commands and hope you never get a merge conflict" which isn't particularly useful because they're now scared of their tools.

We need to teach tools like git (and some editors!) as their own thing, completely separate to programming languages. Not "now we've written some code, let's put it in git" but "here's a tool called git, let's show how it works with some text files"

Honestly - you spend 20 minutes with someone teaching them that git only stores diffs and how that actually works and they leave much more confident and willing to experiment on their own.

A plain text TODO list is absolutely perfect for this, because a merge conflict between two steps on a numbered list is completely intuitive and resolvable. "I've got two 4)s now!" "What's the fix?" "I guess one needs to become 5)?"

(The CLI and naming scheme is total garbage though - biggest hurdle for non-native English speakers IMO)

Honestly - you spend 20 minutes with someone teaching them that git only stores diffs

...except that isn't what git stores (as loose objects); in fact it's one thing that distinguishes git from earlier tools. See eg https://medium.com/@paritosh90/understanding-git-internals-c...

Yeah, I had this misconception for a while.

I think it's useful to understand how git actually stores objects as blobs and trees, but the mental model of "commits are diffs" is still useful. Commands like git-cherry-pick really make the most sense when thought of in terms of diffs. Internally, for a command like that, git is taking the diff and applying it, anyway, so the model isn't really that inaccurate.

I think the main place I've seen where the mental model of "commits are diffs" breaks down and actually leads to significant confusion and/or mistakes, is when the tree ends up in a weird state, such as in the middle of resolving a merge conflict.

In that situation, it's important to keep in mind there's three separate tree-like things: the actual working tree; the index; and HEAD. And git status shows nothing more or less than the diff between the working tree and the index. I've gotten myself out of some confusing situations just by reminding myself of that and thinking things through very carefully.

> Commands like git-cherry-pick really make the most sense when thought of in terms of diffs.

Also "git show <commit>" will show you some metadata + diff, which doesn't really help either.

Then again I'm just happy remembering that parent commit + diff is effectively equivalent to a specific tree. So as long as your think of a patch attached to a specific parent commit you're not really wrong.

> I think the main place I've seen where the mental model of "commits are diffs" breaks down and actually leads to significant confusion and/or mistakes, is when the tree ends up in a weird state, such as in the middle of resolving a merge conflict.

Not really?

With git you just keep track of three things:

1. The actual committed code 2. Code that's in the staging area 3. Code on disk right now

(git has official names for these but I forget)

Then during a rebase, if there a conflict, the base comes from the parent of the commit (in 1) you are applying the new commit on top of and the conflict is basically how the new commit makes changes w.r.t to the latest commit in 1. This conflict is written to 3 for files that are in conflict (and to 2 for files that aren't) and then you can resolve the conflict in 3, move the new code to 2 and commit that to 1. You can think of all of it in terms of diffs.

There's tons of resources about Git out there and a good percentage of them seem to be written by people who don't understand their audience or simply like churning out elitist content nobody wants to read. I personally found 'How git works' by Paolo Perrotta on Pluralsight to be one of the best out there.

> (The CLI and naming scheme is total garbage though - biggest hurdle for non-native English speakers IMO)

I also don’t like the `command <subcommand>` syntax but I’m not sure any naming approach can make life easier/harder for people unfamiliar with the language.

You do réalise that the author of git is not a native speaker of English?

Reply on news.ycombinator.com