How would you create a Git commit using only plumbing commands, without git commit?

## Why the exercise matters `git commit` looks atomic, but it is a sequence of small object writes plus one ref update. Reproducing it by hand is the clearest possible demonstration that Git is a content-addressed object store with a pointer on top, and interviewers use it exactly for that. The four steps map onto the four things Git stores. ## Step 1 — content becomes a blob ``` blob=$(printf 'hello\n' | git hash-object -w --stdin) ``` `git hash-object` computes the object ID of the given content: hash over the header `blob <size>\0` followed by the bytes. Without `-w` it only computes and prints; `-w` also writes the object into the database. `--stdin` reads from standard input; otherwise you name a file. When hashing a working-tree file, Git applies any configured clean filter and end-of-line conversion unless you pass `--no-filters`, and `--path` lets you tell Git which path's attributes should apply when the content is not coming from that path. The blob knows nothing about a filename. Names live in trees. ## Step 2 — the index gains an entry ``` git update-index --add --cacheinfo 100644,$blob,greeting.txt ``` `--cacheinfo` registers an entry directly from an object ID, without the content needing to exist in the working tree — which is why this works even in an empty directory. The mode is one of Git's small fixed set: `100644` for a regular file, `100755` for an executable, `120000` for a symlink (whose blob contains the target path), and `160000` for a gitlink, the submodule commit pointer. `--add` permits creating an entry that is not already tracked. ## Step 3 — the index becomes a tree ``` tree=$(git write-tree) ``` `git write-tree` serialises the current index into tree objects — one per directory, nested — and prints the ID of the top-level tree. Because trees are content-addressed, writing the same content twice yields the same ID and no new storage. Two properties are worth remembering: write-tree reads the *index*, not the working tree, so unstaged edits are invisible to it; and it fails outright if the index contains unmerged entries, that is, entries at stages other than zero left by a conflicted merge. There is also `git mktree`, which builds a tree from a listing on stdin without involving the index at all. ## Step 4 — the tree becomes a commit ``` commit=$(git commit-tree $tree -p $(git rev-parse HEAD) -m "add greeting") ``` `git commit-tree` creates the commit object: exactly one tree, zero or more parents (`-p` per parent, so two or more make a merge, none makes a root commit), author and committer identity lines, and the message, taken from `-m` or from stdin. Identity comes from `user.name` and `user.email` unless overridden by the `GIT_AUTHOR_NAME`, `GIT_AUTHOR_EMAIL`, `GIT_AUTHOR_DATE`, `GIT_COMMITTER_NAME`, `GIT_COMMITTER_EMAIL` and `GIT_COMMITTER_DATE` environment variables — which is exactly how history-rewriting tools reproduce original timestamps. Note what commit-tree does *not* do: it does not move any ref, does not consult `HEAD` for a parent, does not run hooks, and does not update the working tree. It creates one object and prints its ID. ## Step 5 — a ref makes it reachable ``` git update-ref -m "commit: add greeting" refs/heads/main $commit ``` Until this runs, the new commit is unreachable: nothing under `refs/`, no `HEAD`, no index entry points at it, so it is eligible for pruning once the grace period passes. `git update-ref` writes the new value and, with `-m`, appends a reflog entry. Passing the expected old value as a third argument makes the update conditional, which is the safe form in scripts. `git update-ref --stdin` applies many ref updates as one transaction. ## What git commit adds on top The porcelain wrapper contributes: resolving the parent from `HEAD` automatically; opening an editor and applying `commit.template` and cleanup rules; running `pre-commit`, `prepare-commit-msg`, `commit-msg` and `post-commit` hooks; signing when configured; refusing empty commits; and writing a sensible reflog message. All real value — but none of it is the object model. ## Getting the working tree in sync Because the hand-built commit only touched the object database and a ref, your files on disk are unchanged. `git read-tree -u` (optionally with `--reset`) updates the index and working tree from a tree object; `git checkout` or `git switch` is the porcelain equivalent. Forgetting this is the usual reason the exercise appears not to have worked. ## The one-line summary Content to blob (`hash-object -w`), blob to index (`update-index`), index to tree (`write-tree`), tree to commit (`commit-tree`), commit to branch (`update-ref`). Say that back in order and the object model has been demonstrated.