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!

[drbh]

small updates:

• addressed the staged diff changes noted above
• updated the branch with recent changes (used Claude to help resolve merge conflicts)

ready to follow up on the diff changes whenever they are ready