Cole Miller
7587340fb1
This PR updates the git store to not register a change in a repository's merge heads until conflicted paths are seen. We currently use the repository's merge heads only to decide when the list of conflicted paths should be refreshed. Previously, the logic looked like this: - Whenever we see a change in the merge heads, set the list of conflicted paths by filtering the output of `git status`. It turns out that when a conflicting merge takes a while, we can see this sequence of events: 1. We get an event in .git and reload statuses and merge heads. Previously there were no merge heads, and now we have some, but git hasn't finished figuring out which paths have conflicts, so we set the list of conflicted paths to `[]`. 2. Git finishes computing the list of conflicted paths, and we run another scan that picks these up from `git status`, but then we throw them away because the merge heads are the same as in (1). By not updating our stored merge heads until we see some conflicts in `git status`, we delay this step until (2), and so the conflicted paths show up in the git panel as intended. This means that our merge heads state no longer matches what's on disk (in particular, during a clean merge we'll never update them at all), but that's okay because we only keep this state for the purpose of organizing conflicts. Release Notes: - Fixed a bug that could cause conflicted paths to not appear in their own section in the git panel.
Zed
Welcome to Zed, a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.
Installation
On macOS and Linux you can download Zed directly or install Zed via your local package manager.
Other platforms are not yet available:
- Windows (tracking issue)
- Web (tracking issue)
Developing Zed
- Building Zed for macOS
- Building Zed for Linux
- Building Zed for Windows
- Running Collaboration Locally
Contributing
See CONTRIBUTING.md for ways you can contribute to Zed.
Also... we're hiring! Check out our jobs page for open roles.
Licensing
License information for third party dependencies must be correctly provided for CI to pass.
We use cargo-about to automatically comply with open source licenses. If CI is failing, check the following:
- Is it showing a
no license specifiederror for a crate you've created? If so, addpublish = falseunder[package]in your crate's Cargo.toml. - Is the error
failed to satisfy license requirementsfor a dependency? If so, first determine what license the project has and whether this system is sufficient to comply with this license's requirements. If you're unsure, ask a lawyer. Once you've verified that this system is acceptable add the license's SPDX identifier to theacceptedarray inscript/licenses/zed-licenses.toml. - Is
cargo-aboutunable to find the license for a dependency? If so, add a clarification field at the end ofscript/licenses/zed-licenses.toml, as specified in the cargo-about book.