github / github/copilot-cli

Detect file/branch changes

Đang mở
#338 1 bình luận 0 reaction 0 người được giao Xem trên GitHub
area:tools
Ngôn ngữ chính
Shell
Star
11.2k
Fork
1.9k
Merge trung bình
14 giờ 16 phút
Pull request đã merge (30 ngày)
6

Mô tả

### 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:

1. Keep track of all the files we've read (in the last 20 turns, say) and their last-modify times.
2. 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_

Hướng dẫn đóng góp

Mở hướng dẫn đóng góp

Đánh giá

Issue này chưa được đánh giá.

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.