In Git, what does a commit record about its predecessors, and why is history a DAG?

## What a commit actually stores A commit in Git is a small object in the object database. Its content is: one `tree` line naming the root tree object (the whole project snapshot at that point), zero or more `parent` lines naming preceding commits, an `author` line, a `committer` line, optionally a signature, then a blank line and the message. `git cat-file -p HEAD` prints it verbatim. Notice what is absent: no diff, and no branch name. A diff is computed on demand by comparing one commit's tree against another's. A branch name lives in a separate ref file and merely points at a commit; the commit does not know which branches contain it. ## Zero, one, or many parents - **Root commit** — no `parent` line at all. Usually there is exactly one root, but a repository can have several (for example after grafting unrelated histories together, or when a branch was started with `git checkout --orphan`). - **Ordinary commit** — exactly one parent: the commit that was `HEAD` when you ran `git commit`. - **Merge commit** — two or more parents. The order matters and is not arbitrary: the **first parent** is the commit you were on when the merge ran, the second is the branch you merged in. A merge of more than two branches at once (an octopus merge) records three or more parents. ## Why "directed" and why "acyclic" Edges are *directed* because a commit records its parents and nothing records its children. Finding the children of a commit is a search: Git must walk the graph from the refs and see who lists it as a parent. That is exactly why `git log` walks backwards in time by default. The graph is *acyclic* by construction, not by a rule someone enforces. The commit ID is a cryptographic hash of the commit's bytes, and those bytes contain the parent IDs. To make commit A a parent of commit B, A's hash must already exist, so A must already be complete. A cycle would require a commit to contain its own hash, which cannot be constructed. An important corollary: because parents are hashed into the ID, rewriting any commit (amend, rebase, filter) necessarily produces a new ID for it **and** for every descendant. History is immutable; "rewriting" means building a new subgraph and moving refs onto it. ## What the graph buys you Everything higher-level is defined in terms of reachability over these edges. "Is this fix in the release?" is "is commit X reachable from tag v2.0?". Range syntax like `main..feature` is a set difference over reachable sets. Garbage collection keeps objects reachable from refs and reflogs and discards the rest. `git log --graph --oneline` draws the DAG in ASCII, which is the fastest way to see the shape of a merge. ## Frequent misconceptions Candidates often say a commit "stores the changes". It stores a full snapshot tree; the storage layer deduplicates unchanged content and packs deltas, but that is a storage detail, not the data model. Another is that a merge commit contains the merged content "twice" — it has one tree like every other commit, and two parents. A third is that a commit knows its branch; it does not, which is why deleting a branch can strand commits that nothing else points at.