5 ms·

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

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.

cjfd 4y ago
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.
kbr- 4y ago
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.
kreetx 4y ago
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.
AndrewDucker 4y ago
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.
djtango 4y ago
My mental model is each edge is a diff and each node is the aggregate of all edges + the starting state
mattbrewsbytes 4y ago
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.
tgaj 4y ago
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

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.

cjfd 4y ago

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.

kbr- 4y ago

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.

kreetx 4y ago

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.

AndrewDucker 4y ago

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.

djtango 4y ago

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

mattbrewsbytes 4y ago

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.

tgaj 4y ago

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