From RCS to Git:
what changes when history becomes a graph?

Why the shape of the record matters

A revision-control system does more than remember files. Its structure determines what users can compare, how changes can be organized and which facts a future historian might be able to recover. The GNU RCS documentation describes a system organized around multiple revisions of files, including retrieval, logging, identification and merging.^[2] Git's documented data model, by contrast, identifies commits, trees, blobs and tag objects, as well as references and an index.^[4] These are not identical approaches to representing a program's past.

RCS: a disciplined record of file revisions

GNU's project account traces RCS to Walter F. Tichy's work at Purdue University in the early 1980s, describing it as an improvement on earlier source-control approaches including SCCS.^[1] Its manual explains a cycle of checking out a working file, making changes, and checking in a new revision, with per-file revision identifiers and associated metadata.^[2]

What an RCS file can show

The stored history is useful for identifying particular file revisions and comparing their content. It is not, by itself, a complete narrative of who proposed an idea, how a team debated it or when every downstream user adopted it. Those questions often require release notes, mailing-list archives, publications and other contextual material.

Git: commits, trees, blobs and references

The Git documentation describes a commit object as referring to a top-level tree, parent commits, authorship fields and a message. Trees represent directory structures; blobs hold file contents. Objects are identified by cryptographic hashes of type and content.^[4] A commit can have multiple parents, making the stored history a directed graph rather than a simple list.

Snapshots are not merely stored patch lists

Git's core-data-model documentation explains that a commit points to a tree representing the contents of its version, and that Git calculates diffs between commits for display. This distinction is important: the interface often emphasizes changes, while the underlying object model describes complete directory states through reusable objects.^[4]

The 2005 origin belongs to a specific context

The Pro Git history states that the Linux kernel community's relationship with BitKeeper changed in 2005, motivating development of Git with goals including speed, non-linear development and distributed operation.^[3] This is the project's own historical account. A comprehensive independent history would also compare contemporaneous communications and alternative contemporary recollections; this field note does not pretend to have completed that archival investigation.

What history cannot be read from a commit alone

Git's commit fields can record an author, committer, timestamps and a message, but these values do not by themselves settle every question of invention or influence. Commits can be rewritten or replayed, and project decisions may have been made in meetings, emails, patches and private experiments that a repository does not preserve. Git's documented revision syntax provides ways to traverse and select commit histories; it is not a substitute for external corroboration when making historical priority claims.^[5]

Why this comparison matters

Revision systems preserve technical evidence through different abstractions. To reconstruct a history accurately, researchers should know what the system actually stores, when the recorded objects were produced and what evidence exists outside the repository. File revisions, commit graphs and public release dates answer related but distinct questions.

The durable lesson is methodological: use the artifact to support the claim it can support, and explicitly label the questions it cannot answer.