Hacker News Reader

Comment by worldsayshi | Hacker News Reader

I still don't fully understand what the nodes and edges in this graph "is" though. It's not patches. And I can't believe it is "all of the code" in each commit because that sounds very expensive.

View on HN

On a high level, it is "all of the code" in each commit. Node = commit (= all files + some metadata). Edge = pointer to a parent.

On a lower level, a commit is itself a bunch of pointers to files. Different commits can share files. Think about copy-on-write.

I think the confusion is caused by mixing two things - abstract model of git repository where edges are just deltas between images of file system and implementation where this is all optimized. But you don't have to think about implementation when working with git, just abstract model should be enough most of the times. Sure, you have to think about particular implementation of git when for example getting rid of large files in repository

Git essentially shares common files & folders. I.e if you change contents of one file in root folder, then a newly created commit would point to a tree that points to this new file and to all the sibling files and folders which git shares with all other commits.

I believe the latest commit in a branch is "all the code" and prior commits are reverse diffs internally. So more branches and commits doesn't make a repository grow exponentially or anything like that. I'm talking about code/text here, I have no idea if this works as efficient for binaries.

It's not 'all the code', it's the directory info, and links to every file, the vast majority of both of which will already be in the repo.

My mental model is each edge is a diff and each node is the aggregate of all edges + the starting state

Nodes are states of indeed "all of the code". Edges are commits. The "all of the code" thing does sound expensive but it actually is not because git does massive caching. That is what all of the directories in .git/objects are about.

Reply on news.ycombinator.com