Feature Description
@evaline-ju recently pointed out that, after it was already approved and before it was merged, rossoctl/rossoctl#2202 needed a rebase. We need a safe way for clawgenti to be able to rebase its own link fixing PRs.
Proposed Solution
The most common case for the link health fixer is that clawgenti makes PRs updating internal documentation links as code moves around. Given these are low risk fixes, we propose augmenting the link health fixer such that the agent/LLM can assess whether a rebase can be done without any merge conflicts after new commits have been done to the base branch. If not, the agent should post a comment to the PR indicating that a rebase could not be performed without human intervention. Of course, this implies clawgenti keeping track of its open PRs to see if a rebase is needed and updating such state upon merge.
The expectation is that this would greatly expedite the approval process for internal documentation fixes.
Want to contribute?
Additional Context
No response
Feature Description
@evaline-ju recently pointed out that, after it was already approved and before it was merged, rossoctl/rossoctl#2202 needed a rebase. We need a safe way for clawgenti to be able to rebase its own link fixing PRs.
Proposed Solution
The most common case for the link health fixer is that clawgenti makes PRs updating internal documentation links as code moves around. Given these are low risk fixes, we propose augmenting the link health fixer such that the agent/LLM can assess whether a rebase can be done without any merge conflicts after new commits have been done to the base branch. If not, the agent should post a comment to the PR indicating that a rebase could not be performed without human intervention. Of course, this implies clawgenti keeping track of its open PRs to see if a rebase is needed and updating such state upon merge.
The expectation is that this would greatly expedite the approval process for internal documentation fixes.
Want to contribute?
Additional Context
No response