Sharpen the develop-staleness check to a direction-aware content diff#236
Merged
Conversation
Contributor
There was a problem hiding this comment.
Pull request overview
Refines AGENTS.md guidance for detecting when develop is stale relative to main, switching from a commit-history-based check to a direction-aware content diff that better matches this repo’s “bots target both branches” topology.
Changes:
- Replace the
git log origin/develop..origin/mainstaleness check with a directionalgit diff origin/main origin/developcontent check. - Document how to interpret the diff output so “main-only” content stands out from normal “develop-ahead” work.
Replace the `git log origin/develop..origin/main` staleness check with a direction-aware `git diff origin/main origin/develop`. In the bots-target-both model a commit-log check is noisy: it lists routine promotion merges and main-direct bot commits whose content develop already carries via its own parallel bot PRs. A content diff reflects final tree state instead - hunks it would remove are main-only content develop lacks (real staleness); hunks it adds are develop's normal unpromoted work. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
ptr727
force-pushed
the
docs/staleness-check-phrasing
branch
from
2301e69 to
baa40e9
Compare
This was referenced Jul 3, 2026
ptr727
added a commit
that referenced
this pull request
Jul 3, 2026
Follow-up to #236, addressing a Copilot point raised on promotion PR #237: describing `-` lines as "real staleness" and `+` lines as "just" unpromoted work overstates what `git diff origin/main origin/develop` proves. ## Why A hunk where `develop` merely *modified* the same code shows both a `-` (main's old form) and a `+` (develop's new form) - that is normal unpromoted work, not staleness. Calling every `-` line "real staleness" is inaccurate. ## What changed Reframe `-` lines as **main-only differences to inspect** for staleness, and note that a `-`/`+` pair in one hunk is usually just `develop`'s own modification; a `-` line with **no** corresponding `develop`-side replacement is the stronger staleness signal. Targets `develop`; promotion PR #237 will carry it to `main`. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Refines the develop-staleness guidance added in #233. Driving that promotion (#235) exposed that the
git log origin/develop..origin/mainform is noisy in this repo's bots-target-both model.Why
Running
git log origin/develop..origin/mainon a clean, currentdevelopreturned ~50 commits - all routine promotion merges andmain-direct dependabot/codegen commits whose contentdevelopalready carries via its own parallel bot PRs (even--no-merges --cherry-pick --right-onlystill lists them, since parallel bumps have different patch-ids). It cannot cheaply distinguish "develop is missing a main-only fix" from that expected topology noise.What changed
Use a content diff that reflects final tree state, read directionally:
git diff origin/main origin/develop- hunks it would remove are content onmainthatdeveloplacks (real staleness); hunks it adds aredevelop's normal unpromoted work.This also resolves the original Copilot objection to a plain
git diff(that non-empty != stale): the fix is to read the diff's direction, not its emptiness.Verified on #235: for a clean
develop, this diff was exactly the doc filesdevelopadds - nomain-only content - which is the correct "not stale" reading.Issue-closing keywords omitted (targets
develop); no issue to close.