.gitattributes

.yarn -diff

# Forward-merge cascade drivers (ADR 0004 §3).
#
# When a lower release line is merged up into a higher one (`main → next`, and
# `next → major line`), version/changelog differences are mechanical noise, not
# real conflicts. These attributes let them resolve automatically so only a
# genuine code conflict reaches a human via the sync PR (ADR 0004 §4).
#
# IMPORTANT: a `merge=<driver>` attribute is inert on its own — the driver must
# ALSO be registered in the runner's git config. `.github/workflows/forward-
# merge.yml` does this before every merge:
#   git config merge.ours.driver true
#   git config merge.package-json.driver \
#     "node .github/scripts/merge-package-json.cjs %O %A %B %L %P"

# `next` keeps its own CHANGELOG.md; lerna regenerates its entries from the
# merged commits, and per-package changelogs are only the machine record.
#
# CAUTION: `ours` is a blunt "keep our whole file", and like the driver below it
# runs on every local merge, in every direction. It only fires when BOTH sides
# changed the file — nobody hand-edits a generated changelog, so on an ordinary
# branch it never does. The one place it fires in the wrong direction is the
# promotion (`next → main`), where keeping `next`'s file would overwrite the
# stable release history `publish.yml` builds GitHub Release bodies from;
# `/prepare-release` restores `main`'s changelogs after its merge for exactly
# that reason (ADR 0004 §3).
**/CHANGELOG.md merge=ours

# `package.json`: resolve the `version` field to the HIGHER of the two sides and
# merge every other change (e.g. genuine dependency bumps) with a normal 3-way
# merge. A blanket `merge=ours` is rejected — it would silently drop those.
#
# "Higher wins" rather than "ours wins" because this driver, unlike the one
# above, is registered in every developer's git config and therefore runs on
# EVERY merge that touches a manifest — most of them `main` merged INTO a branch
# off it, not the cascade. There "ours" is the fork point, so preferring it
# silently reverted release bumps. The version only ever moves forward on any
# line, so the higher side is the right answer in both directions; for the
# cascade nothing changes, `next` is always the higher one. See the driver.
**/package.json merge=package-json

# `lerna.json` carries the SAME top-level `version` field and diverges between
# the lines for exactly the same mechanical reason — it was missing here, so it
# conflicted as a plain 3-way merge whenever both lines had bumped since their
# last common ancestor (the steady state once a `next` prerelease and a `main`
# release fall between two forward-merges). That turned pure version churn into
# a sync PR, defeating the point of these drivers (found in the #2769
# rehearsal). The package-json driver is generic: it normalises the first
# top-level `"version"` string, which in `lerna.json` is the only one.
lerna.json merge=package-json

# Compiled from `packages/codemods/src/migrations/<id>/entry.md` by
# `pnpm nx build codemods` — an edit here is reverted by the next build, and CI
# fails "Check all generated code is committed" in the meantime. The file says
# so in its header; this marks it for GitHub too, which collapses a generated
# file's diff by default instead of offering it for review like a source file.
# Local `git diff` and the CI check are unaffected.
packages/components/MIGRATION.md linguist-generated=true