In a distributed version-control system, what makes one repository the authoritative one?
answer
- the software has no master copy
- peers, not clients and a server
- convention plus access rules
- what automation reads is what ships
basics
~20 sNothing in the software. Every copy is structurally a peer, so one copy is authoritative only because the team agrees it is and backs that agreement with access rules on its shared pointers and automation that consumes only that copy.
solid answer
~50 sA distributed version-control system has no concept of a master copy: each repository holds objects and pointers, none can compel another, and the address a copy was taken from is stored purely as a convenience. Authority is therefore **social and operational**, assembled from three things — a **convention** that everyone treats one always-reachable copy as the source of truth, **access rules** on that copy deciding who may move which shared pointer, and **automation** that builds and releases only from it, so a change that is not there has in practice not shipped. A useful consequence follows: the shape of collaboration is a choice rather than a constraint. One shared copy everyone publishes to, per-contributor copies whose work is offered to a maintainer, and tiered copies that each take from the one below are all the same model with different conventions.
go deeper
Be ready to say that no copy is special to the software, and that the shared copy is shared because the team agreed on it rather than because the tool marks it as different.
Explain what supplies authority in practice: a copy that is always reachable, rules about who may move its shared pointers, and automation that builds and releases from that copy alone.
Show that you have operated this. Name a failure mode such as two copies both treated as the source of truth, describe the tell, and say how you would collapse them back into one.
Own the governance angle: who decides which copy is authoritative, how the collaboration shape follows from how much you trust contributors, and what relocating the authority actually costs in human terms.
## The software has no opinion In a distributed version-control system every repository is a peer. Two copies of the same project contain the same kinds of thing — immutable history objects and movable pointers — and neither can force the other to accept anything. The address a copy was taken from is stored as a convenience for reaching it again; it confers no status, and deleting it changes nothing about the history. There is no flag, no ownership record and no protocol step that marks one repository as the real one. So the question *which copy is authoritative?* has no answer inside the software. It is answered by the organisation, and once you see that, several confusing behaviours become obvious: why a copy can be perfectly valid and still irrelevant, why moving to a different host is cheap, and why two copies both treated as the source of truth is an organisational failure rather than a technical one. ## What actually creates authority Four things, none of them supplied by the version-control model: 1. **Reachability.** The authoritative copy is one that is always up and reachable by everyone who needs it, rather than a machine that sleeps when its owner closes a laptop. This is an availability property, not a version-control one. 2. **Rules about who may move a shared pointer.** A hosting platform or server layer decides who may advance the line everyone reads. That is the only enforcement in the whole arrangement, and it lives outside the object model. 3. **Downstream consumption.** Whatever builds, tests and releases takes its input from exactly one copy. This is what makes authority real to the business: if a change is not in that copy it did not ship, however finished it looks on someone's machine. 4. **Discoverability.** The address in onboarding notes and in everyone's muscle memory. It sounds trivial and it is half of why an authority is hard to move. ## Shapes this makes possible Because authority is convention, the collaboration shape is a decision about trust rather than a capability of the tool. | Shape | Who may move the shared pointer | How work arrives | Typical use | |---|---|---|---| | One shared copy | everyone on the team | published directly | a team that trusts its members | | Contributor copies plus a maintainer | maintainers only | offered from a contributor's own copy | open contribution from strangers | | Tiered copies | each tier's owner | taken upward from the tier below | very large projects with layered review | All three run the same exchanges over the same objects. Moving between them changes no recorded history at all; it changes who trusts whom. ## Failure modes worth naming in an interview - **Two copies both treated as authoritative.** Work splits, each copy accumulates changes the other lacks, and reconciling them later means combining two long-diverged lines plus a decision about which shared pointer wins. The tell is people asking which copy they should take from. The fix is organisational: name one, and make the other a mirror that only receives. - **Automation reading a different copy from the one people publish to.** Everything looks green and nothing ships. This happens most often after a migration where the pipeline configuration was not part of the move. - **Authority mistaken for durability.** The authoritative copy is where people converge; that is not the same as a copy with retention, verified restores and an off-host location. On a charity donation platform running six contributor copies, the authoritative one is the only copy nobody had ever tried to restore. - **Split authority between history and releases.** When history is authoritative in one place and released artifacts come from another, nobody can answer what is running now from the version-control side alone. ## Moving the authority Because objects are identical wherever they live, relocating the authoritative copy is technically almost free: stand up the new copy, transfer the objects, re-point automation, move the access rules, and make the old one a read-only mirror. What is expensive is everything humans hold — links in documents, addresses on existing machines, and the assumption that the old copy is still current. Plan the move as a communication exercise with a technical component, not the reverse. That asymmetry is the real lesson of the question. The model deliberately removes the notion of a privileged copy, which is exactly why authority costs nothing to relocate and must be maintained deliberately by people.
- What goes wrong when two copies are each treated as authoritative?Work splits. Each copy accumulates changes the other lacks, and reconciling them later means combining two long-diverged lines of history plus deciding which shared pointer wins. The early tell is people asking which copy they should take from. The remedy is organisational rather than technical: name one, and make the other a mirror that only receives.
- Does making a copy authoritative require anything from the version-control software itself?No. It requires a copy that is always reachable, an account model restricting who may move its shared pointers, and everything downstream reading from it. The version-control model contributes only the guarantee that any copy could serve equally well, which is precisely what makes relocating the authority cheap.
A capital city is not geologically different from other cities. It is the capital because the country agrees it is and puts the institutions there.
saying these in an interview costs you the question
- Says the software designates one repository as the master copy
- Thinks the shared copy holds a special kind of history
- Cannot explain how authority is enforced in practice
- Believes moving to a new shared copy requires rewriting history
- Assumes every team must converge on a single shared copy