Repository navigation
overlap: a file main added that a stale lane also adds is not the reader's - #142
Merged
Merged
Conversation
…der's landed() left every whole-file span out of the subtraction, because a whole-file add subsumes the side's own edits to that file. That over-claimed the other way: a reader cut from today's main carries every file main added since a stale lane's base, and when that lane adds them too (half-landed, or squash-merged and never reaped) the report drew ⚠ "the whole file" on paths the reader never opened. Content decides now. A whole-file add or delete is subtracted only where the side's copy of that path is main's copy at the tip byte for byte: the working tree's copy for a live side, the tip's for a branch, and an untracked file counts as the side's own. A copy the side went on to edit keeps the claim, so the add/add two lanes both authored is as loud as before. Co-Authored-By: Claude Fable 5.1 <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
1 participant
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.
What
scruff overlapno longer draws ⚠ "the whole file" on a file the reader inherited from main when a stale lane also adds that file.landed()now subtracts a whole-file add or delete from a side when that side's copy of the path is main's copy at the tip, byte for byte. A copy the side edited, or holds untracked, keeps the whole-file claim.Why
Seen on hausfold.co against the lane
scaffold-desktop-gallery: three loud rows on files the reader had never opened.landed()skipped every whole-file span on purpose, since a whole-file range would subsume a side's own edits to that file. But a reader cut from today's main carries every file main added since a stale lane's base, and when the lane adds them too (half-landed, or squash-merged and never reaped) both sides claim the whole file and the report calls it a collision. Identical content means inherited, not authored, so it comes out. Differing content means the side wrote something there, so it stays.Verify
make checkpasses: 333 bats cases and the three Go packages, on macOS. Two new bats cases sit beside the squash-merge and add/add ones:--committed-only."overlap still calls two lanes creating one new file a collision" is untouched and still passes.
Watch out
SPEC.md §7.3 subtraction 2 is reworded to match. No verb, flag, exit code or
--jsonkey moved, soai/SKILL.mdand the manual are unchanged. The safe direction is still to over-claim: anything git cannot compare stays on the side, and the merge-tree ✗ list is not touched, so a stale lane that conflicts with main on those files still shows there.🤖 Generated with Claude Code