Why is a version-control commit's identifier derived from its own contents?

## How the identifier is produced When a commit is recorded, the system feeds the commit's entire content through a cryptographic hash function: the reference to its file snapshot, the identifier of its parent (or parents), the authorship metadata and recorded times, and the message. The fixed-length output becomes the commit's name. Three consequences follow immediately: - **Nothing about the commit sits outside its name.** Change one character of the message, change a recorded time by one second, change one byte in one file, and the identifier is different. - **The name is not assigned.** No server hands it out and no counter increments. Two machines that independently produce byte-identical commits produce the same identifier without ever talking to each other. - **The name covers the past.** Because the parent's identifier is one of the inputs, a commit's name transitively depends on every commit behind it. ## What that buys 1. **Tamper evidence across the whole chain.** Altering a commit from six months ago changes its identifier, which changes its child's, and so on to the newest commit. There is no way to quietly edit the middle of a history and leave the end looking the same. One trusted identifier therefore vouches for everything reachable behind it. 2. **A cheap equality test.** "Do these two copies of the history agree?" becomes a comparison of two short strings rather than a file-by-file comparison of an entire project across every version. This is the property that makes comparing and verifying histories between machines practical at all. 3. **Names that need no coordination.** Any machine can name a commit without asking permission from a central authority, and identical content always produces the identical name. That is what allows many independent copies of a history to talk about the same commits unambiguously. 4. **Immutability by construction.** You cannot edit a commit, because a commit *is* its contents. Producing different contents produces a different commit. Everything that looks like editing history is really creating new commits, and that is a consequence of the naming scheme rather than a rule someone imposed. | | Assigned sequential number | Content-derived identifier | |---|---|---| | Who issues it | A central authority, in order | Nobody - it is computed | | Survives an edit to the record | Yes, silently | No, by design | | Tells you the order of two records | Yes | No | | Works without coordination | No | Yes | | Detects corruption during transfer | No | Yes | The one thing a sequential number is genuinely better at is human ergonomics: "revision 8412" is easier to say than a long hexadecimal string, and it sorts. That is a real loss. The usual mitigation is that a short prefix of the identifier is enough to name a commit unambiguously within one repository. ## What it does not buy - **It is not proof of authorship.** The author fields are ordinary text supplied when the commit is made; anyone can write anyone's name in them. Establishing that a named person really made a commit requires cryptographic signing, which is a separate mechanism layered on top. - **It is not access control or confidentiality.** Anyone who can read the repository can read every historical state it holds. - **It is not a claim that the content is any good** - only that it has not changed since it was recorded. - **It is not permanently strong on its own.** Hash functions weaken as attacks against them improve, and one function long used for this purpose has had practical collision attacks demonstrated against it, which is why the field has been migrating toward stronger functions. The honest framing is: tamper-evident against accident and casual tampering, and only as strong as the underlying function against a determined attacker. ## Where it shows up in real work When a bike-share operations team promotes a build of the dock-availability service, the deployment record stores the identifier of the commit it was built from. Six weeks later - with half the team hired since the deploy and a 2-day median review wait making anyone's recollection unreliable - the question "is what is running the same code we reviewed?" has an exact answer: compare two identifiers. Nobody has to trust a line name, a build label, or somebody's memory. Those are all movable pointers; the identifier is not, which is why incident timelines and deploy records should cite it rather than a name that can be repointed. The same property explains something juniors find surprising. Correcting a typo in the newest commit's message produces a commit with a *different* identifier, and if that commit had already been shared, the shared copy and yours now disagree about what the newest commit on that line is. The identifier changed because the commit changed. Given how the name is produced, it could not have worked any other way. ## What an interviewer is checking The weak answer stops at "it is a hash, so it is unique." The strong answer explains what the uniqueness is *for*: verification without trust, comparison without cost, and immutability that falls out of the naming rather than being enforced by policy - along with a clear-eyed statement of what the identifier does not prove.