chore: record upstream history without applying obsolete changes

[usercao]

This is an optional repository-history cleanup. It records the archived Microsoft upstream at microsoft/typescript-styled-plugin@3409ef4 as an ancestor without applying any of its obsolete file contents. Its only intended effect is to clear GitHub's "12 commits behind" fork status; it does not address a functional problem.

The head commit uses Git's ours merge strategy:

• its first parent is the current main;
• its second parent is the archived Microsoft upstream;
• its resulting tree is byte-for-byte identical to the current main;
• the PR has 0 changed files, 0 additions, and 0 deletions; and
• no code, dependencies, configuration, or documentation are taken from the old upstream.

The repository currently requires linear history, permits only squash or rebase merges, and has merge commits disabled. Both available PR merge methods would discard the second parent, so they would not accomplish this cleanup. I understand that bypassing or temporarily changing repository protections is an exceptional action, especially for a cosmetic history improvement.

If you think this cleanup is worthwhile, would you be open to temporarily allowing a ruleset bypass for this one update, fast-forwarding main to ab4a46e8c1da4e0eaf6231afd1ed8d4cc6f37046, and then removing the bypass? The current main is the commit's first parent, and the resulting file tree would remain unchanged.

If you would prefer not to make an exception for this cosmetic cleanup, please feel free to close the PR. No repository behavior depends on it, and no further action is necessary.

[changeset-bot]

⚠️ No Changeset found

Latest commit: ab4a46e

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[Copilot]

Copilot wasn't able to review any files in this pull request. Check if the Files changed in this pull request are included in default exclusions.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[pullfrog]

Important

The merge commit this PR exists to create cannot land on main. The active "Main branch" ruleset sets required_linear_history and lists allowed_merge_methods: ["squash", "rebase"], and the repository itself has allow_merge_commit: false, so GitHub will not offer "Create a merge commit" and a direct push of the two-parent ab4a46e is rejected. Merging as-is lands a no-op chore: commit and the fork stays 12 commits behind.

Reviewed changes

Reviewed the 13 commits and the empty file diff on chore/connect-microsoft-history against main at 428a932.

• History-connection merge commit: ab4a46e is a two-parent merge (428a932 plus upstream 3409ef4) whose tree is 4863ac85, byte-identical to main's, so the PR carries 0 files, 0 additions, 0 deletions. Verified with git rev-parse and git diff --stat 428a932...ab4a46e.
• Upstream identity: 3409ef4 is the tip of microsoft/typescript-styled-plugin's main (archived, last commit 2023-04-04, GPG-verified), which is this repository's fork parent. Its tree 4929a5b5 is present locally and is deliberately not applied.
• Divergence claim: git rev-list --left-right --count 428a932...3409ef4 reports 0 12, so main really is 12 commits behind and recording 3409ef4 as an ancestor would clear the fork banner.
• Release-tooling blast radius: none found. scripts/changelog.cjs and scripts/changeset-credits.ts both attribute contributors with git log --reverse --diff-filter=AM -- <changeset path> (no rev range), and the upstream tree carries no .changeset/ directory, so no upstream commit can be credited to a pending changeset. scripts/compare-release.ts reads the published tarball through npm pack, not git history.

⚠️ The one commit this PR adds is forbidden by branch protection

Technical details

# The merge commit cannot land on main

## Affected sites
- `ab4a46e8c1da4e0eaf6231afd1ed8d4cc6f37046` — the PR's only commit, two parents (`428a932`, `3409ef4`). Every merge method other than "Create a merge commit" drops the second parent, which is the entire point of the PR.
- Ruleset `24098529` "Main branch" (`enforcement: active`, `target: branch`, `conditions.ref_name.include: ["~DEFAULT_BRANCH"]`, `bypass_actors: null`): a `required_linear_history` rule, plus a `pull_request` rule carrying `allowed_merge_methods: ["squash", "rebase"]` and `required_approving_review_count: 1`.
- Repository settings: `allow_merge_commit: false`, `allow_squash_merge: true`, `allow_rebase_merge: true`. The merge box therefore offers only squash and rebase, and `required_linear_history` rejects any push that contains a merge commit, so the workaround of merging locally and pushing is closed too.
- `mergeStateStatus` is already `BLOCKED`; the 0-file diff is not what is holding it back.

## Required outcome
- Pick one deliberately, with a maintainer: either drop the goal and record the divergence in prose (`docs/maintenance.md` is the natural home for a one-line note), or relax `required_linear_history` and `allow_merge_commit` for the single merge, land `ab4a46e`, then restore both. The gain is cosmetic (it only clears the "12 commits behind" banner on a fork whose upstream is archived pre-rewrite code); the cost of the second option is a permanently non-linear `main`, against a rule this repository deliberately enabled.

## Suggested approach
- If `main` stays linear, closing the PR is the cheaper correct outcome. There is no functional loss: `3409ef4`'s tree is the old `0.18.x` codebase whose `src/` layout, e2e harness, and release process no longer exist here, and its last four commits are dependabot dev-dependency bumps.
- For whoever takes the linear-history route, two consequences to record: `git log` and `git bisect` now traverse 34 commits between the merge base `4f6ad2a` and `main`'s tip instead of 22, and a bisect step that lands on one of the 12 upstream commits tests that old tree rather than this one (`git bisect --first-parent` avoids it). A later `git merge` of the upstream line would also report those commits as already reconciled, which is misleading in exactly the reverse direction.

## Open questions for the human
- Is clearing a fork banner worth making `main` non-linear, given `required_linear_history` is an active, intentional rule here?

ℹ️ Nitpicks

• The merge commit's message body is empty. If this lands by any route, git log will show 12 dependabot commits whose changes are deliberately absent from the tree, and the in-repo record of why is a PR description that GitHub does not surface in the history. Whatever the surviving commit message is, it should name microsoft/typescript-styled-plugin@3409ef4 as the second parent and say its contents were intentionally not applied.

  ^{｜ Fix it ➔ ｜ View workflow run ｜ Using Space Bunny (free) ｜ 𝕏}

[quantizor]

Idk about this one, I'd rather just disconnect the fork since the original repo is now archived. I prefer the linear history.

[usercao]

That makes sense. I agree that keeping the linear history is the better choice here, especially since the original repository is already archived.

Thanks for taking a look — I'll close this PR.