Beads on a Thread

every commit records its parent - that chain is the history you walk

$ git log --oneline
65427ef salt the water
159fa2b file pasta recipe
bcfb4bd open the recipe book

newest first, following parents

Almost every commit - each sealed record on the thread - carries a small pointer: the id of the commit it was made on top of, its parent. The very first commit has none; a merge carries two (or more). That pointer is the thread. There is no master timeline file: the commit history IS each commit pointing at its parent(s), bead tied to bead. (Git also keeps a private local diary of your own moves - a safety net, never the project's history.)

Maria's repo has three beads on its thread: bcfb4bd began the book, 159fa2b filed the pasta recipe on top of it, and 65427ef salted the water on top of that. Newest first, each holding its parent's id.

$ git cat-file -p HEAD~1
tree 74958c5efb5a8cf71addefb2891ed92113c8ea35
parent bcfb4bdc199227a1cef9e86be1dec9d6a38bddf7
author Maria <maria@example.com> 1767603900 +0000
committer Maria <maria@example.com> 1767603900 +0000

file pasta recipe

one bead's face: its snapshot (tree) and its thread (parent) (HEAD~1 = one save back)

Open one record and the thread is right there, written on its face. The parent line names the bead before; the tree line names the whole-folder snapshot this record seals. A record whose contents changed would change its id - and the id of every bead sealed after it - so a rewrite can never masquerade as the same history to anyone still holding the old ids.

the fork, drawn: two beads tied to one parent

Two beads may share the same parent. Maria opened an experiment from the pasta moment: bd6039d (garlic bread) ties back to 159fa2b - and so does 65427ef on the main line. The thread forks. Nothing moved, nothing copied: two beads simply hold the same parent id.

$ git log --oneline        # standing on garlic-bread
bd6039d try garlic bread
159fa2b file pasta recipe
bcfb4bd open the recipe book

$ git log --oneline --graph --all
* bd6039d try garlic bread
| * 65427ef salt the water
|/
* 159fa2b file pasta recipe
* bcfb4bd open the recipe book

one walk misses the salt bead; --all shows both threads and the fork

Walking the thread only ever goes backward - a bead knows its parent, never its children. Stand on the experiment and walk: you meet the garlic bead, the pasta bead, the first bead - and never the salt bead. Stand on main and the garlic bead is invisible the same way. Neither is gone; each is simply not on the path you walked. Ask for every thread at once and both lines appear.

read it:   * a save   | the other lane   |/ lanes meet

$ git ls-tree --name-only garlic-bread
garlic.md
menu.md
pasta.md

ask the experiment bead: a whole folder, including its new file

Hold the two parallels from the posters together and the model is complete: every bead seals a whole folder (ask any bead with ls-tree and it lists its files), and every file inside answers whole (ask with cat-file and it prints complete contents). Beads hold snapshots; the thread holds the order; diffs are computed between any two beads you name, on demand.

a bead, as you will meet it from here on

Everything the rest of this course teaches is a move on this one picture: naming beads, growing threads, weaving two threads into one, copying a bead across. When a command surprises you, come back here and ask: which beads, which thread, walking which way?