Git partially staged changes

[drbh]

This PR explores the addition of a new feature and UI to improve visibility into partially staged commits.

Currently, the Git panel shows tracked and untracked changes, but it does not clearly distinguish between staged and unstaged changes.

As a result, it’s difficult to quickly see which changes are not staged in the current UI. Both staged and unstaged changes are combined into the Uncommitted Changes multibuffer. This developer experience differs from other editors, most notably VS Code; which presents separate Staged Changes and Changes lists.

Staged and unstaged diffs in multibuffers

This PR introduces an alternative UI for unstaged changes that aligns with the overall Zed experience. Instead of showing changes on a per-file basis, staged and unstaged diffs are each displayed in their own multibuffers, similar to how Uncommitted Changes currently works.

For example the following screenshot shows the current Uncommitted Changes on the left, the Staged Changes in the middle and the Unstaged Changes buffer on the right for comparison

Indicators/interactions

The new multibuffers can be opened in two ways:

1. Via a new U chip, which appears when a file has unstaged changes
2. Via new menu options

(See screenshots below for both interaction paths.)

via the chip

via the menu

Design goals

• minimally intrusive UI changes (small new badge and menu items)
• adhere by Zed'ism (use multibuffer where possible)
• avoid disabling any current interactions (Uncommitted Changes ui is unchanged)
• avoid introducing an app level view mode (no new settings needed)

Experience goals

• make it easy to see what changes are not staged
• make it easy to see that a file has unstaged changes (avoid developers accidently leaving out changes in a commit; a personal issue that I have when using Zed)
• elegantly handle large file's unstaged changes (follows the same collapse and expanding seen in Uncommitted Changes)

How to try

• Clone the repo and run cargo run
• Make a change to a file and stage it
• Make another change to the file (the U indicator will appear)
• Click the U to see the unstaged view

Open questions/rough edges

• determine if this user experience is useful for others
• ensure all interactions work as expected (response to all update cases)

In general I'm really interested in hearing the community's feedback about this interface, more than happy to make any changes or explore a different solution!

Related issue:

• git_ui: Add staged/unstaged view mode like VS Code #36646
• Staged and Unstaged diffs #26560

Release Notes:

• Support partially staged commit multibuffers via a staged and unstaged changes view.

[drbh]

Hi @cole-miller any thoughts on this approach? Thanks in advance!

[SomeoneToIgnore]

Apparently no thoughts from the maintainers due to capacity issues + a draft status for over a month with no activity, so will close as stale for now.

[mathieubellon]

If this branch is our last chance to have this feature, I really hope we can reopen it.

[katie-z-geer]

Hey, our team is going to take a look at this PR, we are interested in this feature. I can't make promises on timeline, but we'll reopen.

[drbh]

@katie-z-geer this is great news!

I'm more than happy to follow up on this PR and make any changes needed.

Please let me know if the team would like to change the approach/implementation in any way and I'll prioritize pushing updates.

Also if helpful, feel free (you or any other team members) to reach out via email if a different communication platform would help get this feature shipped david.richard.holtz@gmail.com

[drbh]

Hi @katie-z-geer just following up to see if there are any updates from the team?

I am a bit hesitant to make any updates to the PR without further feedback/direction from the team.

Thanks again for reopening!

[katie-z-geer]

Hey, I nudged them today. I'll keep you posted!

[ajeetgill]

this is the one of those feature due to which I have to keep my vscode open - only to see the git diff view panel.

[cole-miller]

Hi @drbh, thanks for working on this and sorry for the delay in reviewing. We definitely want this feature in Zed and this is a great start.

Some high-level feedback on the design of the PR as a first pass:

• I think we should adapt the feature a bit to the existing design of Zed by making the unstaged changes multibuffer a mode of the existing uncommitted changes multibuffer (the project diff). When in "unstaged" mode, the project diff would use its existing logic to set excerpt boundaries (and react to changing in git status output, etc.), excerpt that it would skip paths and hunks that are fully staged. We could have an Unstaged | Uncommitted toggle in the toolbar just to the right of the existing Unified | Split toggle for this.
• Creating the readonly staged changes multibuffer using the index text and committed text for each path is reasonable. However, I think we should have open_staged_diff as a primitive on the GitStore just like we have open_uncommitted_diff today. That way the GitStore handles keeping the base text of this diff (the committed text) up to date. To get the main buffers for this multibuffer (containing the index text), we can clone the base_text: Entity<Buffer> off of the unstaged diff, since that buffer is also kept up to date with the latest index text by the GitStore.
• The staged diff should be its own item, like the ProjectDiff is, implemented in a separate module in the git_ui crate, rather than being managed by the GitPanel.

[drbh]

Hi @cole-miller thank you for the feedback! I've reviewed your comments and refactored this feature to move the logic out of the git_panel and into a staged_diff.rs file, added open_staged_diff in git_store.rs and to project.rs in order to follow a similar pattern to open_uncommitted_diff. lastly I've updated the view to have a Unstaged | Uncommitted toggle to switch between the diffs.

please let me know if you have any more feedback regarding the overall approach. I'm planning to dedicate some time to clean up the PR/resolve conflicts and prepare to move it out of draft status, but would appreciate feedback for any other large changes before I tackle those items.

Thanks again!

[cole-miller]

Hi @drbh, thanks for the updates! This second revision is looking good. A couple of things:

• After looking at the code again, I realized we can reuse the ProjectDiff structure for the staged diff as well, like the branch diff does, since it has the same update pattern. Apologies for leading you astray with the feedback about breaking it out into its own module. (It should still be a separate item, like the branch diff is, but I think it doesn't need much unique code outside the Item impl.)
• To model the staged diff correctly, I think we need to refactor how diff bases are managed by BufferDiff and GitStore, so that the HEAD text buffer can be used as a diff base by both the uncommitted diff and the staged diff. This is something I'm working right now; I'll merge it as a separate PR and that should unblock this PR.

[drbh]

@cole-miller thanks for the update, addressing the ProjectDiff changes now - and will be on the look out for your changes to how diffs are managed.

Thanks!

[zed-industries-bot]

	Messages
📖	This PR includes links to the following GitHub Issues: #- 26560 If this PR aims to close an issue, please include a Closes #ISSUE line at the top of the PR body.

Generated by 🚫 dangerJS against 5fa7d91

[cole-miller]

Hi @drbh--

First, thanks again for working on this, and sorry for the prolonged delay.

The first big merge blocker for this was making it possible for the uncommitted diff and the staged diff to soundly share a base text buffer. That was implemented in #58266. #59984 also turned out to be needed because the bug it fixed hit the staged and unstaged diffs especially hard.

The last piece was making these new diffs support the "optimistic staging" behavior that the uncommitted diff already has, so that you get immediate feedback when acting on a hunk from the unstaged diff or the staged diff. This was tricky and ended up touching a lot of the git store and diff code that was involved in this branch, so I pushed it up to the branch directly. In the process, I also realized that having ProjectDiff handle the behavior of all these different diff items was becoming unwieldy, and factored out separate items for each diff multibuffer, with a common DiffMultibuffer backend, and made the unstaged diff its own item instead of a mode of the ProjectDiff (contrary to what I suggested before; sorry for the inconsistency).

Overall, this feature ended up requiring larger changes to our git code than I expected, but I think it's now ready to go, so hitting merge!

[kinson]

Overall, this feature ended up requiring larger changes to our git code than I expected, but I think it's now ready to go, so hitting merge!

@cole-miller a tale as old as time 😂 thanks for your diligence and dedication to implementing this feature 🫶 It's a game changer and, as you can see, will level up many people's Zed experience 🚀

[imzza]

@drbh @cole-miller I’m on Windows and have installed this update. I opened the same repository in both VS Code and Zed. VS Code is showing the unstaged changes, and Zed is also showing the unstaged changes, but I don’t see the “U” icon in Zed’s sidebar indicating that there are unstaged changes.

Although this is a great improvement, I was wondering when we might see an option in the sidebar menu to switch the view and show diffs grouped by staged and unstaged changes. This would make the workflow much easier to use.

One more thing: in the unstaged changes panel, there is only an option to stage the changes. It would be helpful to also have an option or icon to discard unstaged changes directly.

[npv12]

@imzza It is present in the current preview and should be in main release next week if nothing goes wrong

[imzza]

@npv12 Thanks, I have installed the preview release, and it looks great overall. I just have some small feedback I’d like to share.

This looks really good, and I can’t wait to see it in the stable release. I have been waiting for this feature for months.

One thing I noticed: the Staged and Unstaged headers are currently clickable. If we accidentally click on them, all the changes get staged. Could we make these headers non-clickable for staging actions?

Instead, the headers should only be collapsible, allowing users to expand or collapse the staged and unstaged changes sections without accidentally modifying the staging state.