# Objective

Opening a diff against a heavily drifted branch sits on a spinner until
every changed file has loaded. Blob reads were serialized through the
git job queue and enqueued in `open_buffer` completion order rather than
path order, so the blob for the first excerpt could be hundreds of jobs
deep.

## Solution

1. `load_blob_content` skips the job queue — blobs are
content-addressed, so the read doesn't depend on the status snapshot.
2. `DiffBuffer::load` is a lazy future instead of an eagerly-spawned
`Task`, so the consumer picks the concurrency.
3. `DiffMultibuffer` drives those loads through `buffered(16)`.

All three are needed: dropping the queue without bounding forks
thousands of `cat-file` processes, and bounding without dropping it
still serializes.

Trust handling is unaffected, since the untrusted-repo flags are applied
in `GitBinary::build_command` rather than by the queue.

Worth noting that `handle_get_blob_content` is remote-reachable, so a
guest can now put up to 16 `cat-file` processes on the host instead of
queueing them.

## Testing

Added `project_diff::tests::test_excerpts_are_ordered_by_path`, which
pins excerpt order to `PathKey` rather than to load completion order,
using more files than the concurrency limit and several executor seeds.

Green: `cargo test -p git_ui --lib` (131), `cargo test -p project --lib
git_store` (11), `./script/clippy`.

Not tested against a remote or collab project, which is where the
`handle_get_blob_content` change actually matters.

### Numbers

Zed repo against a base ~3000 commits back: 2346 changed files, 1794
with a blob at the merge base. Warm cache, one `cat-file` process per
blob, best of two runs at each concurrency.

| concurrency | total | per blob | speedup |
|---|---|---|---|
| 1 (previous behaviour) | 77.25s | 43.1ms | 1.00x |
| 2 | 17.74s | 9.9ms | 4.35x |
| 4 | 10.05s | 5.6ms | 7.69x |
| 8 | 7.34s | 4.1ms | 10.52x |
| 16 (this change) | 6.63s | 3.7ms | 11.65x |
| 32 | 6.59s | 3.7ms | 11.73x |
| 64 | 7.14s | 4.0ms | 10.82x |

16 is where the curve flattens: 32 buys another 0.7% and 64 regresses,
so there's nothing above it worth the extra in-flight buffers or the
extra concurrent processes on a host serving a remote peer.

At one blob at a time the first excerpt waits at an arbitrary position
in a 1794-deep queue, so roughly 38s on average, which lines up with the
45s full load in the recording below. It's now in the first batch.

## Self-Review Checklist:

- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments — none added
- [x] The content adheres to Zed's UI standards — no UI changes
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable

## Showcase

Opening a branch diff against a base ~3000 commits back, 2346 changed
files. Both clips are cut to 15s to keep the file size down — the before
run took 45s to finish loading.

**Before**


https://github.com/user-attachments/assets/d9475de8-ddd3-48a0-99e2-042a2f655b42


**After**


https://github.com/user-attachments/assets/0bf0e73d-0fac-4c2a-9749-71fee376f260


---

Release Notes:

- Improved how quickly a branch diff shows its first changes when the
branch has drifted a long way from its base