View source for 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 (<code>rev_sha1</code>) ==

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

* '''Storage:''' The hash is stored in the database under <code>revision.rev_sha1</code> (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 <code>rev_sha1</code> field acts as a composite hash combining the individual <code>content_sha1</code> hashes of each slot.
* '''API Exposure:''' You can query the SHA-1 directly via the MediaWiki Action API using:
: <code>action=query&prop=revisions&rvprop=sha1</code>

'''Purpose:''' Unlike Git, where hashes form an immutable cryptographic chain, MediaWiki uses <code>rev_sha1</code> 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 ==

{| class="wikitable sortable"
! Feature !! MediaWiki !! Git
|-
| '''Identity Identifier''' || Monotonic integer (<code>rev_id</code>) || Cryptographic hash (SHA-1 / SHA-256) of object contents
|-
| '''History Structure''' || Relational SQL table pointing to a parent ID (<code>rev_parent_id</code>) || 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 <code>action=query&prop=revisions</code> API and on-wiki diff tools provide functionality analogous to <code>git blame</code> and <code>git diff</code>.
* '''Parent References:''' Each revision explicitly records its predecessor in the database via <code>rev_parent_id</code>, 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 (<code>dumpBackup.php</code>) into a local Git repository for cryptographic verification.