-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update PR with review comments #174
Conversation
previously, the same message thread was stored as separate messages; they are now combined into one unresolved comment with an indicator for the latest message all unresolved comments of this structure as passed to code agent
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey, this is awesome, thanks so much for doing this! I left a bunch of comments below, but many of them are just part of a single section to make it so issue_type
is not null. They can be accepted by going to files and clicking "add suggestion to batch" and then you might need to clean up some stuff I missed. I'm happy to review again when you're done revising.
Regarding the questions:
a. Should every resolved comment open a new PR request, or update the current one?
I think update the current one. It's a little tricky because resolving the comments might mess up the current PR, but maybe that's OK since we can roll back to the previous commit?
b. What happens when 3/5 comments are resolved? How can the user specify which code changes to push on a per comment basis?
Yeah, great question. I'd say that we might want to push anyway and notify the user that we identified 5 comments, but were only able to resolve 3. It'd be awesome if we could actually output that as a structured checklist in markdown like:
I have updated the PR and resolved some of the issues that were cited in the pull request review. Specifically, I identified the following revision requests, and all the ones that I think I successfully resolved are checked off. All the unchecked ones I was not able to resolve, so manual intervention may be required:
- [ ] ...
- [x] ...
- [ ] ...
- [x] ...
- [x] ...
We could even provide this as an in-context example to a prompt in the guess_success()
function that generates the PR message.
c. How are comment dependencies handled? For instance, if two comments address the same part of the codebase, handling them separately may create merge conflicts. Do we expect the user to perform incremental commenting to mitigate this?
I think we'll want to try to resolve all comments at the same time, which will prevent this from being an issue.
Co-authored-by: Graham Neubig <[email protected]>
performing a guess for every comment -> forces one true/false + explanation per comment for previous iteration llm would frequently provide wrong number of explanations (e.g 3 explanations even though 5 comments were provided)
used yellow for the "-" instead of orange; orange doesn't exist in term color options
Feedback has been addressed! Summary of changes
Considerations
Success checklist reference:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great, thanks!
There are lots of "if" statements switching between issue and PR that we might want to refactor a little later to simplify the logic, but overall this is a good change and we should get it in.
I agree that send_pull_request.py
could be made in a separate PR.
Summary
This PR addresses #27
openhands_resolver/resolve_issues.py
with flag--issue-type pr
openhands_resolver/prompts/resolve/basic-followup.jinja
Note: version bumping was not performed on this PR as described in
.openhands_instructions
Future work to be done
a. Should every resolved comment open a new PR request, or update the current one?
b. What happens when 3/5 comments are resolved? How can the user specify which code changes to push on a per comment basis?
c. How are comment dependencies handled? For instance, if two comments address the same part of the codebase, handling them separately may create merge conflicts. Do we expect the user to perform incremental commenting to mitigate this?