2024-02-27 00:09:22 +03:00
|
|
|
[package]
|
2024-03-11 21:35:27 +03:00
|
|
|
name = "worktree"
|
2024-02-27 00:09:22 +03:00
|
|
|
version = "0.1.0"
|
|
|
|
edition = "2021"
|
|
|
|
publish = false
|
|
|
|
license = "GPL-3.0-or-later"
|
|
|
|
|
2024-03-11 21:35:27 +03:00
|
|
|
[lib]
|
|
|
|
path = "src/worktree.rs"
|
|
|
|
doctest = false
|
|
|
|
|
2024-03-05 20:01:17 +03:00
|
|
|
[lints]
|
|
|
|
workspace = true
|
|
|
|
|
2024-02-27 00:09:22 +03:00
|
|
|
[features]
|
|
|
|
test-support = [
|
|
|
|
"client/test-support",
|
|
|
|
"language/test-support",
|
|
|
|
"settings/test-support",
|
|
|
|
"text/test-support",
|
|
|
|
"gpui/test-support",
|
2024-05-11 00:50:20 +03:00
|
|
|
"http/test-support",
|
2024-02-27 00:09:22 +03:00
|
|
|
]
|
|
|
|
|
|
|
|
[dependencies]
|
|
|
|
anyhow.workspace = true
|
|
|
|
client.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
|
|
|
|
itertools.workspace = true
|
|
|
|
language.workspace = true
|
|
|
|
log.workspace = true
|
|
|
|
lsp.workspace = true
|
|
|
|
parking_lot.workspace = true
|
|
|
|
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
|
2024-02-27 00:09:22 +03:00
|
|
|
git2.workspace = true
|
|
|
|
gpui = {workspace = true, features = ["test-support"]}
|
2024-05-11 00:50:20 +03:00
|
|
|
http.workspace = true
|
2024-02-27 00:09:22 +03:00
|
|
|
rand.workspace = true
|
|
|
|
settings = {workspace = true, features = ["test-support"]}
|
|
|
|
pretty_assertions.workspace = true
|