git_ui: Add restore buttons to unstaged diff view

[npv12]

The unstaged diff view introduced in the partially staged changes commit only had a Stage button but no Restore option. This adds:

• A per-hunk Restore button in the inline hunk controls (disabled for new files)
• A Restore button in the toolbar for selected hunks
• A Restore All button in the toolbar to discard all unstaged changes
• A restore method override on UnstagedDiffDelegate for the Restore action

Release Notes:

• Added restore buttons to the unstaged diff view for discarding unstaged changes.

Objective

New unstaged and staged diffs were added in #46541 . However for unstaged changes, only option available is to stage a change. It would also be a common use case to restore the changes. (Like how it is done in uncommitted changes).

Solution

• A per-hunk Restore button in the inline hunk controls (disabled for new files)
• A Restore button in the toolbar for selected hunks
• A Restore All button in the toolbar to discard all unstaged changes
• A restore method override on UnstagedDiffDelegate for the Restore action

Testing

Tested in locally and ensured both features work

Self-Review Checklist:

• I've reviewed my own diff for quality, security, and reliability
• Unsafe blocks (if any) have justifying comments
• The content adheres to Zed's UI standards (UX/UI and icon guidelines)
• Tests cover the new/changed behavior
• Performance impact has been considered and is acceptable

Showcase

Note

I am still learning rust bit by bit. Please let me know if something is massively wrong. This is assisted by AI but reviewed by me with best of my knowledge.

---

Release Notes:

• Added restore buttons to the unstaged diff view for discarding unstaged changes.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 85ff4d428b

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Wait for all diff buffers before restoring all

When the unstaged diff is still loading, this only restores hunks already present in the current multibuffer snapshot. DiffMultibuffer::refresh registers each loaded file as it arrives and doesn't mark the load task ready until after the whole loop, while this toolbar action is enabled as soon as the first restorable hunk is visible; in a repo with many or slow-to-open changed files, clicking “Restore All” during that window leaves later-loaded unstaged files unchanged despite the button claiming to restore all changes.

Useful? React with 👍 / 👎.

[ChristopherBiscardi]

thanks! looks good on the "uncommitted changes" view, but the "Restore" button is missing in the staged changes view.

staged changes can be accessed via right-clicking the file in the git panel as seen here:

"Restore all" is also missing in the staged changes view and the uncommitted changes view, as well as the split-button git panel dropdown

split button dropdown location

[npv12]

thanks! looks good on the "uncommitted changes" view, but the "Restore" button is missing in the staged changes view.
staged changes can be accessed via right-clicking the file in the git panel as seen here:

"Restore all" is also missing in the staged changes view and the uncommitted changes view, as well as the split-button git panel dropdown
split button dropdown location

i am not sure what restore would do in staged changes view? Will it unstage and remove the changes? That seems a bit excessive. For uncommitted changes, if a change is unstaged, we show two options (stage and restore) but we show only "unstage" option when a change is staged. Going with same semantics, Restore should not be part of staged changes

I will add restore all to the dropdown though.

[ChristopherBiscardi]

i am not sure what restore would do in staged changes view?

Presumably the same thing it does in the uncommitted changes view on a staged hunk, which is already implemented in this PR.

[npv12]

i am not sure what restore would do in staged changes view?

Presumably the same thing it does in the uncommitted changes view on a staged hunk, which is already implemented in this PR.

Hi @ChristopherBiscardi I looked into it and hit these blockers.

1. Read-only editor: The staged diff view sets rhs_editor.set_read_only(true) (staged_diff.rs:299). The default restore impl in DiffHunkDelegate checks editor.read_only(cx) and returns early, so it never runs. I can override restore on StagedDiffDelegate to skip that check.
2. Wrong buffer: The uncommitted view's multibuffer wraps the worktree buffer, so restore_diff_hunks edits the right thing. The staged view's multibuffer wraps the index buffer. When resolve_diff_hunks resolves hunks for the staged delegate, hunks.buffer points to the index buffer, not the worktree buffer. Restoring by editing the index buffer would just redo what unstage_staged_hunks already did optimistically. To actually restore the file content in the working tree, I'd need to look up the worktree buffer ID from the git store's buffer_ids_by_index_text_buffer_id mapping and edit that buffer instead. But I am not liking this approach either.

[ChristopherBiscardi]

Thanks for looking into it. the current behavior is fine for this PR.

I ran cargo fmt for CI and kicked off the tests again

[npv12]

Fixed the clippy warning from previous run

[ChristopherBiscardi]

thanks!