git_ui: Add staged/unstaged view mode like VS Code

[mohebifar]

Closes #26560

Release Notes:

• Added a new settings option to git_panel settings display_mode that allows you to switch to a mode similar to VSCode's default which groups files by staged/unstaged instead of tracked vs untracked. If a file has some staged changes and some unstaged changes at the same time, it will appear in both sections just like VSCode.

Screen.Recording.2025-08-20.at.5.06.31.PM.mov

[cla-bot]

We require contributors to sign our Contributor License Agreement, and we don't have @mohebifar on file. You can sign our CLA at https://zed.dev/cla. Once you've signed, post a comment here that says '@cla-bot check'.

[mohebifar]

The default is tracked_untracked, but users can opt in for staged_unstaged

[secondl1ght]

Will this PR be reviewed? This is a highly requested Git feature and would bring Zed closer to having feature parody with the popular VSCode git panel. I am sure there are lots of edge cases to test before merging, but it looks like review hasn't started yet.

[cole-miller]

Hi @mohebifar, thanks for the PR and sorry for the delay in reviewing.

I think we'd be fine having something like this in Zed, but there are some unsolved design issues:

1. It fits poorly with our use of checkboxes for staging and unstaging--having the list entry jump to a different place when you click the checkbox feels bad. (VS Code has a different UI affordance for staging and unstaging that works better with this.)
2. It also doesn't work very well with the diff multibuffer--we don't want to reorder the files in that multibuffer when staging and unstaging, and that means the order of entries in the status list won't agree with the order of files in the multibuffer.

We unfortunately don't have the bandwidth right now to solve these problems, so I'm going to close this PR.

[jerrygreen]

TL;DR – silly comment, skip

---

we don't want to reorder the files in that multibuffer when staging and unstaging, and that means the order of entries in the status list won't agree with the order of files in the multibuffer

I agree! I hated this in VSCode. Though, that is not a reason to close PR is it? You could have just left this notice and give the guy some time to fix the order to be consistent? And then he re-requests review.

It fits poorly with our use of checkboxes for staging and unstaging--having the list entry jump to a different place when you click the checkbox feels bad

Again, it’s fixable, no? It’s possible to (1) remove the heading, and (2) keep the order. Instead of separating by section with a header, it is possible to differentiate the elements by color – red for unstaged files, green for stages ones. And no header. Then the elements won’t jump here and there.

With the mentioned fixes, it will be a handy compact list of files to quickly jump between the files, as well as seeing the state of entire project diff in one screen, rather than relying on manual git commands or third-party software. I wanted the ability to jump between files long ago. I couldn’t use zed's diff editor because it currently doesn’t work well for big changes.

I did read CONTRIBUTING.md and it looks more like a case where PR shouldn’t have been closed… I mean, it obviously looks great, just requires small changes. No?

[mohebifar]

I see your points, and they make a lot of sense @cole-miller. As @jerrygreen suggested, I'm open to making the adjustments. That said, if there's no chance of this getting merged even with the improvements, I'll leave it at that. I still think the default grouping strategy is not that useful (tracked vs untracked) and this will be a great help :)

p.s. in general, what's stopping me from making the switch to Zed is its git and diff views. I find it a bit confusing compared to vscode and lazygit. I really wanna make it happen and I'll be more than happy to help.

[jerrygreen]

After some thought I think what I just said is just silly, because it's literally what tracked/untracked is. Although there's another approach that can be valid:

Clicking the button unstaged will show the only unstaged diff. This will solve the issue with jumping up-and-down UI that I hated in VSCode, and will keep the staged/unstaged logic. (Of course, assuming there are hotkeys for the button, too)

Also I have found that on your screen recording @mohebifar, when you click a file from staged category, it doesn't really show «only the staged diff» like VSCode does, and still shows the entire diff. Which is unhelpful yet, in such an early stage of the feature. But overall idea of having displayed staged/unstaged is still good.

[cole-miller]

Hi @mohebifar, as mentioned in #44379 if you're still interested in working on this we've discussed internally and are ready to work to get it merged!

[mohebifar]

@cole-miller For sure. I'd love to continue contributing. I can continue working on this over the weekend or next week. How does that sound?

[ozturkkl]

This would be insanely useful. I just transitioned from Cursor and this git view not having a staged/unstaged split is killing it for me.

After this a fast follow would be the "split view" diff. It's nice to see some activity on this, that means I don't have to make drastic changes to my flow like killing the UI completely and adding lazygit, which doesn't flow nicely if you want to make changes realtime while reviewing.

[jorgeatlivo]

Really, really looking forward to this PR. Mixed staged and unstaged files is my biggest gripe with the current git implementation. Thanks @mohebifar and Zed team for the work!!

[secondl1ght]

Awesome to see this getting revived, just dropping the related links here: #26560, #26862, #29635. Thanks @mohebifar! And hopefully the Zed team and @cole-miller can work closely with you to get this feature included.

[mohebifar]

@secondl1ght @cole-miller Here's an update on the progress I made: #26560 (comment)