(Temporary page meant to replace CommitSigningPlan)

Commit Audit Trails

Motivation

Accurately tracking a commit's "chain of custody" can be difficult in a distributed environment, even working completely openly. Commits are created at a different time from when they are added to canonical history, and are typically changed in the process (perhaps by rebasing onto other new commits). Beyond chain of custody, organizations often encode workflow in commit messages by embedding a vocabulary of "attestations": code review and testing sign-offs are two notable examples. Using DVCS this means that for K changes of custody, a commit will have K different IDs.

Background

At present, Mercurial offers no standard mechanism for distinguishing the author of a commit from the committer: the person who added the commit to a given repository. Mercurial only has an author field.

The EvolveExtension facilitates workflows that rewrite history by storing and sharing out-of-band "obsolescence markers" that specify temporal relationships between local commits. These markers could only be used to construct an audit trails if every "revision" of the commit is stored locally, and these markers deliberately prevent sharing all but the latest revision of a commit.

Design

Each entry in the audit trail is represented as an extra field with a well-known key of the form "sigN", where N is a non-negative integer. Newer audit log entries have a larger N. The "sig0" key is reserved for the original author of the commit to provide attestations.

CategoryProject