Skip to content

v0.6.0 — Merge in any order, by any method

Latest

Choose a tag to compare

@dougstanford dougstanford released this 13 Aug 01:39
2c01138

The staleness guard now records a content hash per user-facing surface (a manual-surfaces block) in place of the single commit sha it stamped before. A surface's hash changes exactly when that surface's content does, so the guard compares hashes at the current commit rather than counting commits since a base.

Because the marker is content, not a commit sha, the manual no longer conflicts when branches land in parallel:

  • Any order. An update rewrites only the hash line for a surface it actually changed, so two branches touching different surfaces merge without a conflict whichever lands first. Two branches touching the same surface still collide on that one line, which is the reconciliation the manual needs.
  • Any method. Squash and rebase merges are safe again — a content hash can't be orphaned by a rewritten sha — so the repo no longer requires merge commits.
  • Shallow clones work. The check reads only the tree at the current commit, so CI no longer needs fetch-depth: 0.

A manual carrying only the old base sha is migrated to the new block by one update run.

See TICKET-0006 for the full requirements and decisions.