Feature request: "review-only" changes — visible in the PR diff, excluded from the merge

[harshit-2004]

Body:

Summary

I'd like a way to include changes in a pull request that are visible to reviewers inline during review but are automatically excluded when the PR is merged, so they never land in the main branch's file history.

Motivation / Use case

When I open a PR, I often make temporary edits purely to demonstrate or exercise the change — for example:

• mocking a client to force a failure path,
• hardcoding a value to trigger a specific scenario,
• scaffolding / test-harness code that shows how I verified the change.

I want reviewers to see these edits inline in the diff so they understand exactly how I tested, and I'd like the edits to stay discoverable later for anyone doing similar testing. But I don't want them merged
into the main branch, because they'd pollute the real source.

Current workarounds and why they fall short

• Separate commit, dropped before merge (interactive rebase): works, but rewriting the branch after review creates a new PR revision and can invalidate approvals already given.
• Scaffolding on a separate branch/tag, linked from the PR: preserves the code, but reviewers don't see it inline in the main diff.
• Documenting the edits in the commit message / PR description: visible, but it's plain text — not a reviewable, checkout-able diff.

None of these give the core thing: inline-visible in review, excluded from merge, without churning revisions or breaking approvals.

Proposed feature (open to alternatives)

Some mechanism to mark specific hunks / files / commits as "review-only," e.g.:

• an annotation (commit trailer, PR marker, or a path convention like *.review-only) that the merge automatically strips, or
• tooling support to exclude specific commits on merge without producing a post-approval revision.

I'm flexible on the exact design — the goal is: changes reviewers can see and reuse later, that never reach the main branch's files.

Known tradeoff (calling it out honestly)

I recognize the main objection: if reviewers approve a diff that includes review-only content and it's excluded at merge, then the approved artifact differs from the merged artifact, which can weaken the audit
guarantee code review provides. Any acceptable design would need to preserve traceability — e.g. the excluded content stays permanently linked/visible from the merged PR, and it's unambiguous to reviewers which
parts are review-only. I'd love the community's input on how to keep that guarantee intact.

Questions

1. Is there an existing capability that already supports this that I've missed?
2. If not, would the team consider supporting it?

I'd like to help build this

I'm not just requesting this — I'd be glad to contribute to the implementation. I can help with:

• a concrete design proposal / spec for the "review-only" marker and the merge-time behavior,
• a prototype (e.g. the path-convention or commit-trailer approach, whichever the maintainers prefer),
• tests and documentation.

If there's interest, point me at the right area of the codebase and any contribution guidelines, and I'll put together a design doc or a proof-of-concept PR to iterate on.

Thanks!