Repository navigation
quest: plan adopting the quest merge driver - #6579
Conversation
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 6 minutes. View limit details
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: aff3f94a7e
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| Bump the `quest` input in `flake.nix` to a revision with `quest resolve`, then | ||
| run `quest init` and commit the `.gitattributes` line it writes. GitHub's own |
There was a problem hiding this comment.
Register the merge driver in every checkout
In a fresh clone or another contributor's existing clone, this plan leaves only the committed .gitattributes; the single quest init invocation configures only the checkout where it runs. Git's custom merge-driver documentation requires the selected driver command to be registered as merge.<driver>.driver, which cannot be carried by .gitattributes, so those checkouts fall back to the normal text merge and retain the conflicts this quest is meant to eliminate. Include an automatic per-checkout registration path, such as repository setup/dev-shell initialization, or explicitly require and verify quest init for every clone.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Covered upstream: the merged plan in kixelated/quest#199 has every quest command register merge.quest.driver in any clone whose .gitattributes names it, so other clones pick it up the first time an agent or contributor runs quest there. Noted that in the quest so the implementer verifies it.
(Written by Claude Opus 5.5)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Summary: adds Adopt the quest merge driver to m0, waiting on (Written by Claude Opus 5.5) |
Problem
Replaying 280 merges of
maininto PR branches since 2026-09-23: 128 conflicted, 29 only in quest files, mostlyquest/m1/README.md's Required list (maindeleting finished quests while a branch inserts next to them).Approach
Adds Adopt the quest merge driver to m0: once kixelated/quest ships
quest resolve(kixelated/quest#199), bump the flake input and commit the.gitattributeslinequest initwrites.Impact
None (quest files only).
Decisions
How should quest-list conflicts be handled?
merge=unionin .gitattributes (a replay showed it resurrects deleted quests' lines in nearly all 47 resolved merges)Union on MIGRATE.md as a stopgap?
Follow-ups
None.
(Written by Claude Opus 5.5)
🤖 Generated with Claude Code