Revision hashing in MediaWiki

Q: Does MediaWiki have an edit hash capability or any Git-like qualities with respect to tracking changes (and verifying changes) and so forth?

A: MediaWiki does calculate content hashes, but its architecture is fundamentally different from Git's cryptographic DAG (Directed Acyclic Graph).

Revision Content Hashing (rev_sha1)

MediaWiki calculates a SHA-1 hash for the content of every edit.

• Storage: The hash is stored in the database under revision.rev_sha1 (encoded in base-36 format).
• Multi-Content Revisions (MCR): In modern MediaWiki versions, a page can hold multiple "slots" (e.g., main wikitext, structured metadata). The rev_sha1 field acts as a composite hash combining the individual content_sha1 hashes of each slot.
• API Exposure: You can query the SHA-1 directly via the MediaWiki Action API using:

action=query&prop=revisions&rvprop=sha1

Purpose: Unlike Git, where hashes form an immutable cryptographic chain, MediaWiki uses rev_sha1 primarily for:

• Duplicate detection: Fast checks to see if an edit actually modified the text or reverted back to an identical previous version.
• Integrity & corruption checks: Verifying client-transmitted payloads against database writes.
• Revision deduplication: Avoiding redundant blob storage in backend object systems.

---

MediaWiki vs. Git: Architecture Differences

Feature	MediaWiki	Git
Identity Identifier	Monotonic integer (rev_id)	Cryptographic hash (SHA-1 / SHA-256) of object contents
History Structure	Relational SQL table pointing to a parent ID (rev_parent_id)	Cryptographic Merkle DAG (commits hash parents + tree states)
Tamper Evidence	Low (database rows can be altered or pruned without invalidating future revisions)	High (modifying any past commit breaks downstream hashes)
Branching & Merging	Linear, single-branch trunk per page (conflicts must be resolved inline)	Full distributed branching, three-way merging, and rebasing
Storage Model	Centralized SQL database + external blob storage	Distributed content-addressable object store

---

Git-Like Qualities That Do Exist

• Line-by-Line Attribution: The action=query&prop=revisions API and on-wiki diff tools provide functionality analogous to git blame and git diff.
• Parent References: Each revision explicitly records its predecessor in the database via rev_parent_id, allowing linear traversal of history.
• Three-Way Merge on Conflict: When two users edit a page simultaneously, MediaWiki attempts an automated, diff3-style three-way merge. If changes do not overlap, it commits automatically; otherwise, it triggers an edit conflict resolution screen.

If you need true Git-level cryptographic immutability, audit verification, or offline branching for wiki content, common solutions include deploying file-backed wiki engines like Gitit or Gollum, or streaming MediaWiki revisions via XML dumps (dumpBackup.php) into a local Git repository for cryptographic verification.

Readings

Wikipedia

• Git (software)
• MediaWiki
• SHA-1 cryptographic hash function
• Merkle trees and hash graphs
• Directed acyclic graph (DAG)
• Content-addressable storage
• Revision control systems
• Three-way merge algorithm
• Base36 encoding scheme

See also

• MediaWiki database layout
• Multi-Content Revisions
• Version control systems
• Content-addressable storage
• Data integrity