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
d36ebc8c74
zed/crates/worktree/Cargo.toml

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

59 lines
1.3 KiB
TOML
Raw 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",
Extract `http` from `util` (#11680) This avoids the CLI linking libssl etc... Release Notes: - N/A
2024-05-11 00:50:20 +03:00
"http/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
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
smol.workspace = true
sum_tree.workspace = true
text.workspace = true
util.workspace = true
[dev-dependencies]
clock = {workspace = true, features = ["test-support"]}
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
gpui = {workspace = true, features = ["test-support"]}
Extract `http` from `util` (#11680) This avoids the CLI linking libssl etc... Release Notes: - N/A
2024-05-11 00:50:20 +03:00
http.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
rand.workspace = true
settings = {workspace = true, features = ["test-support"]}
pretty_assertions.workspace = true
Reference in New Issue Copy Permalink