zed icon indicating copy to clipboard operation
zed copied to clipboard

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

Open tmolteno opened this issue 9 months ago • 2 comments

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

tmolteno avatar May 22 '25 09:05 tmolteno

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!)

probably-neb avatar May 27 '25 14:05 probably-neb

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) https://github.com/zed-industries/zed/issues/31168#issuecomment-2912782088

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 https://github.com/zed-industries/zed/issues/31168#issuecomment-2912782088, 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.

tmolteno avatar May 28 '25 21:05 tmolteno

Hi there! 👋 We're working to clean up our issue tracker by closing older bugs that might not be relevant anymore. If you are able to reproduce this issue in the latest version of Zed, please let us know by commenting on this issue, and it will be kept open. If you can't reproduce it, feel free to close the issue yourself. Otherwise, it will close automatically in 14 days. Thanks for your help!

github-actions[bot] avatar Nov 19 '25 11:11 github-actions[bot]