Git: Zed crashes when git changes are shown in a repo with a large number of untracked files

[tmolteno]

Summary

Zed consumes all RAM (8GB laptop) and eventually crashes when git changes is viewed on a file in a project with a large number of untracked files.

Description

Steps to trigger the problem:

1. Created a project on a subdirectory inside a large github repo with many untracked files. Mine has ~ 360 untracked files (the result of git status -s . | wc). The git panel also shows into many files within folders ignored by .gitignore.
2. Click to view the Git panel (this doesn't cause a problem)
3. Now click on a file that has changes and is tracked.
4. Zed will show a panel called uncommitted changes, that contains changes from all untracked files as well. Then zed will proceed to use all system ram and crash.
5. Zed will now crash every time I open it as the uncommitted changes are shown each time it launches!

Actual Behavior: Show the changes in the single tracked file.
Expected Behavior: Shows all changes in all untracked files and crashes.

Zed Version and System Specs

Zed: v0.187.5 (Zed)
OS: Linux Wayland debian 13
Memory: 7.5 GiB
Architecture: x86_64
GPU: Intel(R) HD Graphics 620 (KBL GT2) || Intel open-source Mesa driver || Mesa 25.0.5-1

[probably-neb]

I think this is a known issue around the limits for multibuffers (what we're using to show all the uncommitted changes in a single file). I don't think we have an issue for it (feel free to make it with stats on how many files were untracked!).

A workaround for now is to invoke Zed on the command line with the -n flag to create a new workspace that won't reload your open files (I recommend committing the untracked files first!)

[tmolteno]

The untracked files are ignored by a .gitignore (they're byproducts of a large scale computation, and consist of thousands of files). They should never be committed.

…

On Tue, May 27, 2025 at 4:42 PM Ben Kunkle ***@***.***> wrote: *probably-neb* left a comment (zed-industries/zed#31168) <#31168 (comment)> I think this is a known issue around the limits for multibuffers (what we're using to show all the uncommitted changes in a single file). I don't think we have an issue for it (feel free to make it with stats on how many files were untracked!). A workaround for now is to invoke Zed on the command line with the -n flag to create a new workspace that won't reload your open files (I recommend committing the untracked files first!) — Reply to this email directly, view it on GitHub <#31168 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAU47VYPU2EBUL7VD7SPI33AR2T3AVCNFSM6AAAAAB5VNWX2OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSMJSG44DEMBYHA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

-- Dr Tim Molteno Electronics Research Department of Physics, University of Otago TART Project <https://tart.elec.ac.nz> lead.