How does Git store a stash internally — what commits and refs does git stash push create?

## The claim "A stash is a commit" sounds like trivia, but it explains nearly every stash behaviour that confuses people: why entries renumber, why `git show` works on them, why a restore can conflict, and why entries survive branch switches. ## What `git stash push` builds When you stash, Git creates commit objects — not a patch file, not a scratch directory: 1. **An index commit.** A commit whose tree is the current index (your staged content), with `HEAD` as its parent. Its message looks like `index on <branch>: <sha> <subject>`. 2. **An untracked commit**, only when you used `-u` or `-a`. Its tree contains the untracked (and with `-a`, ignored) files. It has no parent. 3. **The stash commit.** Its tree is the full **working-tree** state. Its parents, in order, are: the `HEAD` commit you were on, the index commit, and — if present — the untracked commit. Its message is the familiar `WIP on <branch>: <sha> <subject>`, or your own text when you pass `-m`. Having both a working-tree tree and an index tree recorded is what allows `git stash apply --index` to reproduce your original staged/unstaged split; without `--index`, Git just applies the working-tree state and everything comes back unstaged. After writing these objects, Git resets your working tree and index to `HEAD`. ## Where it is stored The stash commit is pointed to by a single ref: **`refs/stash`**. It is deliberately not under `refs/heads/`, so it is not a branch, does not appear in `git branch`, and is not pushed by a normal push. ## Why `stash@{n}` renumbers One ref can only point at one commit, so how do multiple stashes coexist? Through the ref's **reflog**. Each time you stash, `refs/stash` is updated to the new stash commit and the previous value is recorded in the reflog for that ref. `stash@{0}` means "the current value of `refs/stash`", `stash@{1}` means "its value one entry ago", and so on — the same `<ref>@{n}` syntax you use for any ref. Two consequences follow directly: - **Numbers are positions, not identities.** Creating a stash shifts every existing entry down by one, so a `stash@{2}` you noted five minutes ago may now be `stash@{3}`. Always re-list before acting on a numbered entry. - **`git stash list` is a reflog listing**, which is why entries carry the branch and commit they were made on in their message. ## Inspecting with ordinary commands Because they are commits, normal plumbing and porcelain work: ``` git stash list git show stash@{0} # the stash's diff git log --graph --oneline refs/stash git cat-file -p refs/stash # raw commit object: tree and parents git rev-parse stash@{1} # the commit id of an entry ``` `git cat-file -p refs/stash` is the demonstration that settles the question: you can literally read the two (or three) `parent` lines. ## Why restores conflict Applying a stash is a three-way merge, not a file copy: Git merges the stash's working-tree state against your current `HEAD` using the stash's first parent as the base. If the branch has moved or you have other changes, the merge can conflict exactly as any merge can. That is a direct consequence of the storage model, not a quirk of the command. ## What `drop` and `clear` actually do `git stash drop` removes an entry from the reflog of `refs/stash`; `git stash clear` empties the whole thing. Neither immediately deletes the underlying commit objects — they simply stop being referenced, which is the ordinary Git story for unreferenced objects. That is why `git stash branch` can hand an entry a real branch: it is just pointing a branch ref at commits that already exist. ## Stashes are repository-wide, not per branch One more thing the model explains: `refs/stash` is a single per-repository ref. Stashes are not scoped to the branch you made them on — you can pop a stash created on `feature/a` while sitting on `main`. The branch name in the entry's message is documentation, nothing more. Whether the restore applies cleanly depends on the merge, not on where you made it. ## What a strong answer covers Name `refs/stash`, describe the commit with `HEAD` and the index commit as parents (plus the untracked commit with `-u`), explain `stash@{n}` as reflog positions on that ref, and draw one conclusion from the model — renumbering, conflicts as merges, or `--index` being possible because the index tree was recorded.