Post AYcnmdwg5B367UXf1c by mikee@social.lol
 (DIR) More posts by mikee@social.lol
 (DIR) Post #AYYzubCmZn0OktnMMi by amolith@nixnet.social
       2023-08-09T19:07:59.904957Z
       
       1 likes, 2 repeats
       
       For those who find git difficult to use and don't know a ton about it, understanding its underlying data structure helped me a lot. A git repo is a merkle treehttps://en.wikipedia.org/wiki/Merkle_treeEach commit is a node that builds on its predecessor and branches are, well, branches. When you check out a branch and run git log, you're seeing the linear history of that particular branch from the most recent node to the root of the tree, often your "initial commit". HEAD is a pointer to whatever node you're currently at; when you git checkout an old commit, you're moving HEAD so it points to that older node. When you checkout main, you're moving HEAD so it points to whatever node is furthest down that branch. Removing secrets from a repo is not feasible for large projects because it requires finding the commit introducing that secret and changing it. Because all child commits contain a hash of its parent commit, changing a parent invalidates every single one of its children and grandchildren and great grandchildren and so on. The parent has changed, so its hash changed, so its child needs to be updated to include the new hash of its parent. That cascades through the rest of the tree. You then have to force-push to your remote because your local tree has wildly diverged from the remote tree; you're telling the remote to throw whatever tree it has away (the one containing your secrets) and just accept the tree you're sending it (the one without your secrets). Your local tree and your remote tree are now the same … but your other contributors might have pulled the commit with your secrets. Now their tree is wildly diverged from the remote tree and they have two options: save their work somewhere else, rm -rf their local repo, and re-clone the new tree or do a git reset <commit preceding the one with secrets> and git pull. Git reset <commit> discards all of the nodes on your branch up to and _not_ including <commit>. It's like pruning a branch that's grown too long; you cut it back then let it re-grow differently.I hope this helps :neofox_heart:
       
 (DIR) Post #AYc9RYy9OP84RFcl7o by wolf480pl@mstdn.io
       2023-08-11T07:30:03Z
       
       0 likes, 0 repeats
       
       @amolith i'm glad this helps you understand git, but technically it's wrong:- HEAD is the root, initial commit is the leaf- merge commits exist, which make it not a tree, but a directed acyclic graph - git is a Merkle DAG
       
 (DIR) Post #AYcASHWzoPBSbDpUEC by wolf480pl@mstdn.io
       2023-08-11T07:48:40Z
       
       0 likes, 0 repeats
       
       @roboneko @amolith well in a DAG you can have multiple roots.But what I meant is, it's a node with no parents, as in, no other node has its hash.That's also technically incorrect since you can checkout an old commit, so it's more like the root of your current view of the DAG.On other sense, it's the only node whose hash you need to know in order to verify everything below.
       
 (DIR) Post #AYcnmdwg5B367UXf1c by mikee@social.lol
       2023-08-11T07:14:11Z
       
       0 likes, 0 repeats
       
       @amolith wait, are git branches basically mutable blockchains? Or rather, given the chronology, are blockchains basically immutable git branches?
       
 (DIR) Post #AYcnmesob1YN1nk5dw by amolith@nixnet.social
       2023-08-11T15:10:54.422615Z
       
       0 likes, 0 repeats
       
       @mikee the only thing that makes blockchains immutable is that they're distributed and getting everyone to mutate them the same way from the same point isn't feasible. You can't remove secrets from large repos for exactly the same reason blockchains are "immutable"Blockchains are hash chainsGit repos are hash trees (multiple chains branching from each other)Yes, "blockchain tech" has been around for decades :meowLul:
       
 (DIR) Post #AYcpqpzJRzieXGtzai by mikee@social.lol
       2023-08-11T15:13:18Z
       
       1 likes, 0 repeats
       
       @amolith does that mean that we can basically blame crypto on Linus Torvalds? 🤪
       
 (DIR) Post #AYcqZnsI9cgT0r3kie by qeef@en.osm.town
       2023-08-11T08:02:50Z
       
       0 likes, 0 repeats
       
       @amolith It confuses me a little bit, because wiki says that [for Merkle tree] the child nodes are hashed into parents so the root contains all the hashes of all the nodes. However, in git, new commit contains the hash of the preceding ones and root (initial commit) cannot have any hash yet.
       
 (DIR) Post #AYcqZoyM4Z80Pwu6oC by amolith@nixnet.social
       2023-08-11T15:42:11.498765Z
       
       0 likes, 0 repeats
       
       @qeef Ah yes, I'd forgotten the wikipedia page says that. In practise, I _believe_ that both directions are still referred to as Merkle Trees; a parent containing hashes of its children vs children containing a hash of its parent.
       
 (DIR) Post #AYcrZSjcqqJNP3PJTc by feld@bikeshed.party
       2023-08-11T15:53:00.457498Z
       
       2 likes, 0 repeats
       
       >  root (initial commit) cannot have any hash yetI swear I went down this rabbit hole once and there's a empty root / commit hash or something they use for this, but I might be hallucinating
       
 (DIR) Post #AYcvQ9NJrQm8ZPmxpA by qeef@en.osm.town
       2023-08-11T16:02:39Z
       
       1 likes, 0 repeats
       
       @feld @amolith You are not. Wanna more? You may have multiple init commits (root, no parent hash) in a single repository.