-
Notifications
You must be signed in to change notification settings - Fork 757
Description
Describe the feature or problem you'd like to solve
Right now, if Copilot edits a file, then the developer edits it more, then Copilot tries to edit it again (which is super common for me), it can get confused. It either silently reverts the manual change, or hits "match not found" errors on its subsequent errors and gets confused, sometimes saying the file got corrupted. In a more extreme case, the developer might switch Git branches mid-session.
Proposed solution
Proposed solution:
- Keep track of all the files we've read (in the last 20 turns, say) and their last-modify times.
- Each time a turn starts, check all those files and see if any have been changed. If so, include extra context in the LLM call, e.g., "The following files have changed since you last read them: .... If you're making further edits to those files, consider re-reading the latest state. But if the files are not related to your ongoing work, you do not need to re-read them."
(Alternative: use actual file watchers, but TBH I think that may be overkill)
Benefit:
If you're co-editing files alongside Copilot, which I think is a common flow for some devs including me, you will then see Copilot start turns by saying "Let me recheck {file} to see what changed" before making subsequent valid edits.
Challenge:
While we can auto-update our internal timestamp info when the agent writes a file using the file-write tool, we can't necessarily detect when it causes a file write using the shell tool. So we might give it false positives (telling it about changes that it knows about because it intentionally caused them itself). This might slow it down. We might be able to mitigate by rechecking all the timestamps before and after synchronous shell calls, but that's only OK if we're checking < 50 files (say) otherwise it starts to become a different perf issue in itself.
What about changing Git branches?
It might be too expensive to run git CLI commands around every turn to check if the branch changed. So maybe we'd do this if and only if we detect a file change using the mechanism from above.
Then we could notify the agent that the Git branch has changed and prompt it with something like: "The Git branch has changed from x to y. If you understand why this has happened based on what the user is doing, you may continue. If it's not clear why this change happened, ask the user for clarification about how to proceed".
Example prompts or workflows
No response
Additional context
No response