The Commit Graph (DAG)
You made five commits building config.json, then one git reset seemed to delete the last one. Nothing was erased: every commit still sits on disk, and finding the pointer that orders them explains exactly where it went.
- ▸Nothing keeps your commits in order; each carries the hash of the one before it.
- ▸A reset that seems to delete a commit only moves a ref and logs the move; the commit sits on disk for weeks.
- ▸Git journals every place a branch has pointed, so work you think you destroyed stays findable.
Five commits built up config.json one change at a time. Git does not read that order from a numbered list, and it does not sort by timestamp. (The reflog does log each move of main, but git log prints the same five commits with .git/logs/ deleted.) So how does the fifth commit know the fourth came before it? Open the fifth commit's stored text with git cat-file -p and read it: a tree line for its snapshot, author and committer lines, a message like Add timeout to config.json, and one more line you have not met yet: parent followed by a 40-character hash. That hash is the fourth commit. Each commit stores, inside itself, the identity of the one it was built on. The order is not kept in a list somewhere; it is spread across the commits, one back-pointer each.