Merge main into dev to reconcile release history #4

Merged

hannah-vernon merged 2 commits from chore/reconcile-main-into-dev into dev

2026-08-21 13:37:22 -05:00

hannah-vernon commented

2026-08-21 13:36:50 -05:00

Owner

Summary

Merges main into dev to reconcile branch history. No file content changes.

Why

PR #3 (dev to main) is flagged "out-of-date with the base branch".

Every dev to main release PR leaves a merge commit on main that never travels back to dev. In this repository that is d9f4e07, the merge commit from PR #1. dev therefore does not contain main's tip, and Forgejo's check looks at ancestry rather than content.

The content has never differed. git diff origin/dev origin/main shows only PR #3's own changes, and d9f4e07 introduces no files of its own.

What this does

Merges origin/main into a branch cut from dev, producing a merge commit and nothing else.

Verified:

git diff between the pre-merge and post-merge commit is empty. History only.
git merge-base --is-ancestor origin/main HEAD returns 0, so main becomes an ancestor of dev and PR #3 stops being out of date.
dotnet test: 22 passed, 0 failed.

I first tried this as a direct push to dev. The pre-receive hook declined it, which is correct: dev is protected and requires a pull request. Hence this branch.

Alternative

PR #3 can be merged as-is. The warning is informational and the merge would succeed, since the content is already correct. This PR exists to clear the warning and stop the offset compounding with each release.

Recurrence

This will happen after every release unless the pattern changes. Two options, worth deciding separately and not urgently:

Raise a routine back-merge PR like this one after each dev to main merge. One extra PR per release, full history preserved.
Switch dev to main merges to fast-forward or rebase in the repository settings, so no merge commit lands on main in the first place. Cleaner, but it changes how release history reads.

Assumptions

Reconciling by merging main into dev is preferred over rewriting history on either branch. Nothing here is rebased or force-pushed.
Merging this before PR #3 is the intended order. PR #3 will pick up this commit automatically, since a pull request tracks its head branch.

## Summary Merges `main` into `dev` to reconcile branch history. **No file content changes.** ## Why PR #3 (`dev` to `main`) is flagged "out-of-date with the base branch". Every `dev` to `main` release PR leaves a merge commit on `main` that never travels back to `dev`. In this repository that is `d9f4e07`, the merge commit from PR #1. `dev` therefore does not contain `main`'s tip, and Forgejo's check looks at ancestry rather than content. The content has never differed. `git diff origin/dev origin/main` shows only PR #3's own changes, and `d9f4e07` introduces no files of its own. ## What this does Merges `origin/main` into a branch cut from `dev`, producing a merge commit and nothing else. Verified: - `git diff` between the pre-merge and post-merge commit is empty. History only. - `git merge-base --is-ancestor origin/main HEAD` returns 0, so `main` becomes an ancestor of `dev` and PR #3 stops being out of date. - `dotnet test`: 22 passed, 0 failed. I first tried this as a direct push to `dev`. The pre-receive hook declined it, which is correct: `dev` is protected and requires a pull request. Hence this branch. ## Alternative PR #3 can be merged as-is. The warning is informational and the merge would succeed, since the content is already correct. This PR exists to clear the warning and stop the offset compounding with each release. ## Recurrence This will happen after every release unless the pattern changes. Two options, worth deciding separately and not urgently: - Raise a routine back-merge PR like this one after each `dev` to `main` merge. One extra PR per release, full history preserved. - Switch `dev` to `main` merges to fast-forward or rebase in the repository settings, so no merge commit lands on `main` in the first place. Cleaner, but it changes how release history reads. ## Assumptions - Reconciling by merging `main` into `dev` is preferred over rewriting history on either branch. Nothing here is rebased or force-pushed. - Merging this before PR #3 is the intended order. PR #3 will pick up this commit automatically, since a pull request tracks its head branch.

hannah-vernon added 2 commits

2026-08-21 13:36:50 -05:00