Hacker News Reader

Comment by rich-tea | Hacker News Reader

Git is not hard. It's very simple. But people learn it the wrong way. You have to learn it from the DAG up. If you cannot grasp how the DAG works you'll forever be reading and writing articles like this one which do not help you to learn.

This is a horrible article. You should not bookmark it or use it. If you're not a programmer, you shouldn't use git. If you are a programmer, do yourself a favour and spend a day going through something like this: https://wyag.thb.lt/

It will make you better at git and better at programming. Git is a powerful tool and you need to learn how to use it. Imagine if people read articles like this one instead of learning how to drive.

View on HN

Don't gatekeep. Git isn't just for programmers.. it's for people that are learning.. people using it in non programming capacities and tons more. Telling people to "git gud" is not helpful. Not everyone knows, or indeed cares to know what a Directed Acyclic Graph is, and sites like this help people's anxiety who are just learning, or who have already screwed up and just want a solution.

I agree that the DAG and Git storage model are at least not particularly complicated. The problem is that the Git user interface (the CLI, plus various concepts that are used in other interfaces as well, like refspecs, that are not fundamental to Git) is not very simple, and the correspondence between the DAG and mutations you may wish to perform, and Git commands, is often fairly obtuse and opaque.

I care about the internals of git about as much as I care about the internals of my filesystem.

It's probably helpful to know some basics, but do I need to know intimate details of my filesystem to use cp, mv, shell redirection? No. For most basic actions it Just Works™.

The problems in git are purely user-interface based. Other distributed systems have proven you can make a dcvs with a reasonably friendly UI.

That's because a file system is something you already understand, even if you've never actually used an old fashioned paper filing system. The software is providing you with something you understand.

Git is not providing you with something you understand. It is providing you with a DAG and you neither understand what that is or why you need it. The DAG is not the "internals of git". This is the big mistake. It is git. Everything about git is about building that DAG.

Git isn't hard but it's usually taught like absolute shit. From the get go you're told to use 4 commands, 2 of which are usually not explained and when they are it's often hand wavey. From there on its usually people pontificating about high level philosophy while failing to give concrete working examples. At least that was my experience.

I'm decent at got now for the work I do so I'm cool with it. It really is an awesome tool. But for some reason its just collectively taught like shit.

It's just one of those tools that is very foreign to new users, but once you know how to use it, you can't remember not knowing how to use it because it's so easy... this is like a lot of programming, actually.

That's true. Probably why the teaching has such a knowledge gap.

Write yourself a git is a wonderful site to read through, even if you don't end up doing the implementation. It really helped my git usage!

But git isn't just for programmers, and cheat sheets can be good for people who just want to dip their toes in.

I think you are right about the DAG. Once I understood what the high-level data structure of git is, many branch related commands immediately made sense and it was suddenly very easy to use. Many of my colleagues haven't taken the time to learn that and continuously struggle with basic commands.

Honestly the DAG isn't the whole story. The distributed nature also adds a twist that makes things entirely difficult, and the obtuseness of the commands is yet another layer of difficulty. People have every right to expect git commit to commit their changes to the remote repo. And it very well could, but it just doesn't happen to. Similarly you can't tell me with a straight face that notion of having to 'git add' a file you just deleted in order to be able to commit that change is somehow intuitive. I could go on and on but the point is knowing the DAG is hardly the end of the story.

I agree it's not the end of the story, but without that knowledge, learning git is almost impossible. Even with DAG knowledge, some commands are hard to remember.

What's a DAG?

Directed acyclic graph. Basically each git commit points to zero or more parent commits (usually one, zero for root commits, more than one for merge commits) and that forms a DAG.

https://medium.com/girl-writes-code/git-is-a-directed-acycli...

Unfortunately this article, like almost all others, is still wrong because it looks like commits get mutated when you rebase and the old commits disappear.

It is very important to understand that commits (in fact, all blobs) are immutable in git. You can only make new things. You can't modify old things. Git doesn't delete anything for a while either.

Directed Acyclic Graph.

Graph = graph, a structure composed of a set of objects (nodes or vertices) with links between them (edges).

Directed = the edges have an orientation / a direction.

Acyclic = there's no cycle, you can't come back to a node (in a directed graph you have to follow edge direction).

In Git, the commit objects are nodes, the "parent" link(s) is a directed edge, and because commit objects are immutable you can't create a commit which refers to one of its "descendants" and thus the graph is acyclic.

The gatekeeping is strong on this one.

Reply on news.ycombinator.com