Tree view for Git Panel

[notpeter]

Summary

Support for a nested tree-view in the Git Panel.

Description

See also:

• Files in nested directories are hard to distinguish #26097
• Make filenames in git panel match filenames in multibuffer diff #27230

Screenshot

Nate's mockup:

[FrGoIs]

I decided to work on this issue. Here are my assumptions from the mock and the discussion (corrections are most welcome):

• The toggle at the right switches between the view that we want to build and the existing one (for how files are represented, the panel header will remain as in the mockup).
• The button next to the word Changes (containing the lines changed) will open the diff.
• The checkbox at the start will check or uncheck all items (stage all or unstage all) even if they are untracked.

[VLZH]

@FrGoIs I will wait for your implementation! I am a big user of git tree view in VsCode. I think this is very useful because folders group related files together, which makes it easier to review changes in the right order.

[YukiOta]

+1, I’m also excited about this. Tree view would make reviewing changes much easier.

[douglance]

the lazygit implementation is really nice.

• clicking folders opens the diff as a list view of a series of files.
• clicking a file opens only that file's diff.

I really like that functionality because it gives you both views based on the user's choice in the moment, rather than having to toggle.

the list view of all diffs is actually confusing to me when I dont expect it because I'll scroll through and i'll be in a different file without knowing it.

it would be great if the git diff view follows the same sorting rules for the file explorer panel view, and would be great to see file icons there as well (file icons are more important thatn the change icon to me, and change status could be a color of the text instead of the change icon).

I would also really like the ability to view the entire file rather than just the area around changes. Users have to jump back and forth from the diff to the file and back to fully understand the changes if they're not totally familiar with the full contents of the file. It should be a choice at least.

The VSCode system of having a staged area and unstaged area is helpful as well. It's lower cognitive overhead vs. inspecting all the icons.

thanks so much for working on this! its the only reason I can't use zed full time.

[spiff1281]

+1

[Yaphet2015]

I decided to work on this issue. Here are my assumptions from the mock and the discussion (corrections are most welcome):

• The toggle at the right switches between the view that we want to build and the existing one (for how files are represented, the panel header will remain as in the mockup).
• The button next to the word Changes (containing the lines changed) will open the diff.
• The checkbox at the start will check or uncheck all items (stage all or unstage all) even if they are untracked.

Can't believe Zed doesn't have this feature yet. Looking forward to your implementation

[Hamza5743]

Bumping as this will be super useful 👍

[ctop007]

This has been one of the main reasons I haven’t switched to using Zed as my main editor yet. How’s the progress on this feature? Any idea when the Git change tree view might be available?

[xipeng-jin]

Hello there, I have finished a first iteration prototype of this feature. Please check out the recording here.

Screen.Recording.2025-10-31.at.3.32.24.PM.mov

The followings are currently supported features:

1. Toggles between nested and flat file views with an icon segmented switch. Displays total staged entries, change count text, and a focused pill highlighting aggregate additions and deletions (+/−) for the repository.
2. Provides quick "Stage/Unstage All" control with contextual tool-tip and tri-state checkbox that reflects full/partial staging.
3. Supports per-entry diff stats badges (adds/deletes) that bubble up to directories in tree mode and stay in sync with async diff-stat streaming.
4. Allows expanding, collapsing folders in the tree with cached state so directory badges immediately reflect children.
5. Maintain the original Integration with overflow menu actions and stage buttons alongside the header.
6. Renders a dashed separator under the header so the control bar stays visually distinct from the file list.

I would like to hear any early feedback for the current UI design and expected behavior, so that I can make some adjustment before submitting the PR. I am still working on optimizing the performance, fixing some bugs, and tidy things up. But I am approaching there.
I also want to appreciate the contribution from @FrGoIs for his PR #38190 to fix the dashed border. If you are still working on this feature, I would like to pair with you for shipping this feature faster. Thank you.