Git Beta: File stays tracked after staging and removing changes

[devzeth]

Summary

File stays tracked after staging and removing changes. Issue is because we don't unstage the chunk when user makes an edit.

Steps to trigger the problem:

1. Open a file, make a change.
2. Go to the git panel, and click on the file.
3. Stage the chunk.
4. Remove the changes manually and save.

Actual Behavior:
The file remains in the git panel, tracked.
Expected Behavior:
File should have been removed from the git panel

Gif reproducing the issue:

Zed Version and System Specs

Zed: v0.178.0 (Zed Dev 3bec4eb)
OS: macOS 15.3.1
Memory: 48 GiB
Architecture: aarch64

If applicable, attach your ~/Library/Logs/Zed/Zed.log file to this issue.

Zed.log

[cole-miller]

This is working as intended, although it does reveal a gap in what you can do with the current diff hunks interface that we hope to close with additional features (namely, you can't interact with a hunk from the HEAD<->index diff that doesn't intersect any hunk from the HEAD<->working copy diff).

It happens because the stage operation updates the contents of the file in the git index, and editing the file afterward doesn't affect what's in the index.

Note that there's a git: restore action and a "Restore" button in the floating hunk controls that will do what you want here, i.e. undo the hunk's change in both the buffer and the git index. We just don't do this for normal edits, and I don't think we should---there are legitimate cases where you want to stage a specific version of a file and then edit it afterward without further updating the index (e.g. cases where you might use the [e]dit option of git add -p).