zed-industries/zed
1
1
Fork 0
mirror of https://github.com/zed-industries/zed.git synced 2024-11-08 07:35:01 +03:00
Code Issues Packages Projects Releases Wiki Activity
main
zed/crates/worktree/Cargo.toml

62 lines
1.4 KiB
TOML
Raw Permalink Normal View History

Extract project_core out of project (#8438) That's done to unblock work for dynamic tasks (`task` crate has to access the worktree yet it is a dependency of a `project`). Release Notes: - N/A
2024-02-27 00:09:22 +03:00
[package]
Rename 'project_core' crate to 'worktree', make it just about worktrees (#9189) This is just a refactor. I noticed that we now have a `project_core` crate, which mainly contains the `Worktree` type and its private helpers, plus the project's settings. In this PR, I've renamed that crate to `worktree` and did some minor simplification to its module structure. I also extracted a new `WorktreeSettings` settings type from the `ProjectSettings`, so that the worktree settings could live in the worktree crate. This way, the crate is now exclusively about worktree logic. Release Notes: - N/A
2024-03-11 21:35:27 +03:00
name = "worktree"
Extract project_core out of project (#8438) That's done to unblock work for dynamic tasks (`task` crate has to access the worktree yet it is a dependency of a `project`). Release Notes: - N/A
2024-02-27 00:09:22 +03:00
version = "0.1.0"
edition = "2021"
publish = false
license = "GPL-3.0-or-later"
Rename 'project_core' crate to 'worktree', make it just about worktrees (#9189) This is just a refactor. I noticed that we now have a `project_core` crate, which mainly contains the `Worktree` type and its private helpers, plus the project's settings. In this PR, I've renamed that crate to `worktree` and did some minor simplification to its module structure. I also extracted a new `WorktreeSettings` settings type from the `ProjectSettings`, so that the worktree settings could live in the worktree crate. This way, the crate is now exclusively about worktree logic. Release Notes: - N/A
2024-03-11 21:35:27 +03:00
[lib]
path = "src/worktree.rs"
doctest = false
Move Clippy configuration to the workspace level (#8891) This PR moves the Clippy configuration up to the workspace level. We're using the [`lints` table](https://doc.rust-lang.org/cargo/reference/workspaces.html#the-lints-table) to configure the Clippy ruleset in the workspace's `Cargo.toml`. Each crate in the workspace now has the following in their own `Cargo.toml` to inherit the lints from the workspace: ```toml [lints] workspace = true ``` This allows for configuring rust-analyzer to show Clippy lints in the editor by using the following configuration in your Zed `settings.json`: ```json { "lsp": { "rust-analyzer": { "initialization_options": { "check": { "command": "clippy" } } } } ``` Release Notes: - N/A
2024-03-05 20:01:17 +03:00
[lints]
workspace = true
Extract project_core out of project (#8438) That's done to unblock work for dynamic tasks (`task` crate has to access the worktree yet it is a dependency of a `project`). Release Notes: - N/A
2024-02-27 00:09:22 +03:00
[features]
test-support = [
"language/test-support",
"settings/test-support",
"text/test-support",
"gpui/test-support",
Update http crate name (#15041) Release Notes: - N/A
2024-07-24 01:01:05 +03:00
"http_client/test-support",
Extract project_core out of project (#8438) That's done to unblock work for dynamic tasks (`task` crate has to access the worktree yet it is a dependency of a `project`). Release Notes: - N/A
2024-02-27 00:09:22 +03:00
]
[dependencies]
anyhow.workspace = true
clock.workspace = true
collections.workspace = true
fs.workspace = true
futures.workspace = true
fuzzy.workspace = true
git.workspace = true
Add support for self-hosted GitLab instances for Git permalinks (#19909) This PR adds support for self-hosted GitLab instances when generating Git permalinks. If the `origin` Git remote contains `gitlab` in the URL hostname we will then attempt to register it as a self-hosted GitLab instance. A note on this: I don't think relying on specific keywords is going to be a suitable long-term solution to detection. In reality the self-hosted instance could be hosted anywhere (e.g., `vcs.my-company.com`), so we will ultimately need a way to have the user indicate which Git provider they are using (perhaps via a setting). Closes https://github.com/zed-industries/zed/issues/18012. Release Notes: - Added support for self-hosted GitLab instances when generating Git permalinks. - The instance URL must have `gitlab` somewhere in the host in order to be recognized.
2024-10-29 19:31:51 +03:00
git_hosting_providers.workspace = true
Extract project_core out of project (#8438) That's done to unblock work for dynamic tasks (`task` crate has to access the worktree yet it is a dependency of a `project`). Release Notes: - N/A
2024-02-27 00:09:22 +03:00
gpui.workspace = true
ignore.workspace = true
language.workspace = true
log.workspace = true
parking_lot.workspace = true
settings: Load `.zed/settings.json` even if .gitignored (#13370) This fixes #4432 by ensuring that we scan & watch the `.zed` folder, just like we watch the `.git`, for changes. Release Notes: - Settings are now loaded from local `.zed/settings.json` files even if they are `.gitignore`d. ([#4432](https://github.com/zed-industries/zed/issues/4432)). Co-authored-by: Bennet <bennet@zed.dev>
2024-06-21 19:39:14 +03:00
paths.workspace = true
Extract project_core out of project (#8438) That's done to unblock work for dynamic tasks (`task` crate has to access the worktree yet it is a dependency of a `project`). Release Notes: - N/A
2024-02-27 00:09:22 +03:00
postage.workspace = true
rpc.workspace = true
schemars.workspace = true
serde.workspace = true
serde_json.workspace = true
settings.workspace = true
project search: Increase perf up to 10x by batching `git status` calls (#16936) ***Update**: after rebasing on top of https://github.com/zed-industries/zed/pull/16915/ (that also changed how search worked), the results are still good, but not 10x. Instead of going from 10s to 500ms, it goes from 10s to 3s.* This improves the performance of project-wide search by an order of magnitude. After digging in, @as-cii and I found that opening buffers was the bottleneck for project-wide search (since Zed opens, parses, ... buffers when finding them, which is something VS Code doesn't do, for example). So this PR improves the performance of opening multiple buffers at once. It does this by doing two things: - It batches scan-requests in the worktree. When we search, we search files in chunks of 64. Previously we'd handle all 64 scan requests separately. The new code checks if the scan requests can be batched and if so it, it does that. - It batches `git status` calls when reloading the project entries for the opened buffers. Instead of calling `git status` for each file, it calls `git status` for a batch of files, and then extracts the status for each file. (It has to be said that I think the slow performance on `main` has been a regression introduced over the last few months with the changes made to project/worktree/git. I don't think it was this slow ~5 months ago. But I also don't think it was this fast ~5 months ago.) ## Benchmarks | Search | Before | After (without https://github.com/zed-industries/zed/pull/16915) | After (with https://github.com/zed-industries/zed/pull/16915) |--------|--------|-------|------| | `zed.dev` at `2b2a501192e78e`, searching for `<` (`4484` results) | 3.0s<br>2.9s<br>2.89s | 489ms<br>517ms<br>476ms | n/a | | `zed.dev` at `2b2a501192e78e`, searching for `:` (`25886+` results) | 3.9s<br>3.9s<br>3.8s | 70ms<br>66ms<br>72ms | n/a | | `zed` at `55dda0e6af`, searching for `<` (`10937+` results) | 10s<br>11s<br>12s | 500m<br>499ms<br>543ms | 3.4s<br>3.1s<br> | (All results recorded after doing a warm-up run that would start language servers etc.) Release Notes: - Performance of project-wide search has been improved by up to 10x. --------- Co-authored-by: Antonio <antonio@zed.dev>
2024-08-27 12:59:59 +03:00
smallvec.workspace = true
Extract project_core out of project (#8438) That's done to unblock work for dynamic tasks (`task` crate has to access the worktree yet it is a dependency of a `project`). Release Notes: - N/A
2024-02-27 00:09:22 +03:00
smol.workspace = true
sum_tree.workspace = true
text.workspace = true
util.workspace = true
[dev-dependencies]
Clean up formatting in `Cargo.toml` (#18632) This PR cleans up some formatting in some `Cargo.toml` files. Release Notes: - N/A
2024-10-02 17:38:23 +03:00
clock = { workspace = true, features = ["test-support"] }
Extract project_core out of project (#8438) That's done to unblock work for dynamic tasks (`task` crate has to access the worktree yet it is a dependency of a `project`). Release Notes: - N/A
2024-02-27 00:09:22 +03:00
collections = { workspace = true, features = ["test-support"] }
Avoid holding worktree lock for a long time while updating large repos' git status (#12266) Fixes https://github.com/zed-industries/zed/issues/9575 Fixes https://github.com/zed-industries/zed/issues/4294 ### Problem When a large git repository's `.git` folder changes (due to a `git commit`, `git reset` etc), Zed needs to recompute the git status for every file in that git repository. Part of computing the git status is the *unstaged* part - the comparison between the content of the file and the version in the git index. In a large git repository like `chromium` or `linux`, this is inherently pretty slow. Previously, we performed this git status all at once, and held a lock on our `BackgroundScanner`'s state for the entire time. On my laptop, in the `linux` repo, this would often take around 13 seconds. When opening a file, Zed always refreshes the metadata for that file in its in-memory snapshot of worktree. This is normally very fast, but if another task is holding a lock on the `BackgroundScanner`, it blocks. ### Solution I've restructured how Zed handles Git statuses, so that when a git repository is updated, we recompute files' git statuses in fixed-sized batches. In between these batches, the `BackgroundScanner` is free to perform other work, so that file operations coming from the main thread will still be responsive. Release Notes: - Fixed a bug that caused long delays in opening files right after performing a commit in very large git repositories.
2024-05-25 03:41:35 +03:00
env_logger.workspace = true
Extract project_core out of project (#8438) That's done to unblock work for dynamic tasks (`task` crate has to access the worktree yet it is a dependency of a `project`). Release Notes: - N/A
2024-02-27 00:09:22 +03:00
git2.workspace = true
Clean up formatting in `Cargo.toml` (#18632) This PR cleans up some formatting in some `Cargo.toml` files. Release Notes: - N/A
2024-10-02 17:38:23 +03:00
gpui = { workspace = true, features = ["test-support"] }
Update http crate name (#15041) Release Notes: - N/A
2024-07-24 01:01:05 +03:00
http_client.workspace = true
Extract project_core out of project (#8438) That's done to unblock work for dynamic tasks (`task` crate has to access the worktree yet it is a dependency of a `project`). Release Notes: - N/A
2024-02-27 00:09:22 +03:00
pretty_assertions.workspace = true
Clean up formatting in `Cargo.toml` (#18632) This PR cleans up some formatting in some `Cargo.toml` files. Release Notes: - N/A
2024-10-02 17:38:23 +03:00
rand.workspace = true
worktree: Depend on `rpc` with `test-support` feature in tests (#18866) This PR updates the `worktree` crate to depend on `rpc` with the `test-support` feature flag when running tests. This fixes an issue I was seeing locally when trying to run tests in the `worktree` crate: ``` λ cargo test -p worktree -- test_repository_subfolder_git_status Compiling worktree v0.1.0 (/Users/maxdeviant/projects/zed/crates/worktree) error[E0432]: unresolved import `rpc::AnyProtoClient` --> crates/worktree/src/worktree.rs:39:18 | 39 | use rpc::{proto, AnyProtoClient}; | ^^^^^^^^^^^^^^ no `AnyProtoClient` in the root For more information about this error, try `rustc --explain E0432`. error: could not compile `worktree` (lib test) due to 1 previous error ``` Release Notes: - N/A
2024-10-08 20:07:34 +03:00
rpc = { workspace = true, features = ["test-support"] }
Clean up formatting in `Cargo.toml` (#18632) This PR cleans up some formatting in some `Cargo.toml` files. Release Notes: - N/A
2024-10-02 17:38:23 +03:00
settings = { workspace = true, features = ["test-support"] }
Reference in New Issue Copy Permalink