Resolved merge conflicts still show as conflicted in Git panel
Summary
After successfully resolving Git merge conflicts, the Git panel continues to display files in a conflicted state
Steps to trigger the problem:
- Create a merge conflict between two branches
- Open conflicted file in Zed and resolve markers
- Save file and stage changes by
git add . - Observe Git panel state
Actual Behavior: Files remain under Conflicts section
Expected Behavior: The resolved files should move from Conflicts section to Tracked section.
Zed Version and System Specs
Zed: v0.180.0 (Zed Dev 044eb7b99048e79da5aa3f2dd489ff3ed8f97a32) (Taylor's Version) OS: Windows 10.0.22631 Memory: 15.4 GiB Architecture: x86_64 GPU: NVIDIA GeForce RTX 2060 with Max-Q Design || NVIDIA || 517.00
Hey, thanks for reporting. Unfortunately, as of right now Windows is not an officially supported platform, so I expect many of the Git related features to not work properly.
@cole-miller Thank you for the git merge conflicts highlights 🎉 Ref: https://github.com/zed-industries/zed/pull/28065
Does is close this issue ?
I noticed a new inconsistency—files that should be in a conflicted state are incorrectly listed under the Tracked section in Zed’s Git panel, instead of the Conflicts section.
Zed: v0.188.0 (Zed Dev 74ca74caf2182c3cd0a8258cc0e4f1440804abec) (Taylor's Version) OS: Windows 10.0.22631 Memory: 15.4 GiB Architecture: x86_64 GPU: NVIDIA GeForce RTX 2060 with Max-Q Design || NVIDIA || 517.00
happens on linux too
The behavior described in the OP is intentional. We clear out the conflicts section only when the repository's merge state changes, not when staging or unstaging; otherwise the entries in that list would jump from one section to the other when staging and unstaging from within Zed, which we don't want. Note that the icon and color-coding for the entry do change, so you can tell it's not actually conflicted anymore that way.
@feeiyu the behavior you're seeing in your second post is different and not intended. Do you have a reproducer?
@cole-miller Thank you for explaining the intentional behavior behind conflict section persistence.
@feeiyu the behavior you're seeing in your second post is different and not intended. Do you have a reproducer?
I think this issue already fixed.