Additionally this extracts more functionality into the RunnableVariant which is renamed to GpuiRunnable.
Release Notes:
- N/A
---------
Co-authored-by: Lukas Wirth <lukas@zed.dev>
Co-authored-by: Cole Miller <cole@zed.dev>
Closes#42217
Release Notes:
- Added/Fixed/Improved ...
added "Create Pull Request" Command when searching on the command
Palette
For more details, please refer to the issue, thank you.
---------
Co-authored-by: dino <dinojoaocosta@gmail.com>
Closes#26424
Supersedes #35328
Originally, `git::blame` uses its own `ParsedCommitMessage` as the
source for the commit information, including the PR section. This
changes unifies this with `git::repository` and `git_ui::git_panel` by
moving this and some other commit-related structs to `git::commit`
instead, and making both `git_ui::blame_ui` and `git_ui::git_panel` pull
their information from these structs.
Release notes :
- (Let's Git Together) Fixed the commit tooltip in the git panel not
showing information like avatars.
---------
Co-authored-by: Cole Miller <cole@zed.dev>
Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com>
This PR ensures truncation works for the file paths, which should set up
the stage for when the new GPUI `truncation_start` method lands
(https://github.com/zed-industries/zed/pull/45122) so that we can use
for them. In the process of doing so and figuring it out why it wasn't
working as well before, I noticed some opportunities to clean up some UI
code: removing unnecessary styles, making the file easier to navigate
given all of the different UI conditions, etc.
Note: You might notice a subtle label flashing that comes with the label
truncation and that's a standalone GPUI bug that's also visible in other
surface areas of the app. I don't think it should block these changes
here as it's something we should fix on its own...
Release Notes:
- N/A
I could not find any related issue, but at least I want to use the git
panel like this :)
Being used to `lazygit`, this PR makes navigation of the git panel more
similar to the CLI tool.
Instead of selecting -> enter'ing for skimming each file, I just want to
move between the files in the git panel and have the diff multibuffer
advance to the appropriate file. This also adheres to the behavior of
the outline panel, which I like better.
If the multibuffer is not active, it behaves same as before (just
selecting the file in the panel, nothing else).
I did not modify existing `menu::Select*` actions in case anybody still
prefers previous behavior.
https://github.com/user-attachments/assets/2d1303d4-50c8-4500-ab3b-302eb7d4afda
Release Notes:
- Improved navigation of the git panel, by advancing the "Uncommitted
Changes" multibuffer to the current selected file. To restore the old
behavior, you can bind `up` and `down` to `menu::SelectPrevious` and
`menu::SelectNext` under the `GitPanel` context in your keymap.
Co-authored-by: Cole Miller <cole@zed.dev>
Closes #ISSUE
Problem:
- The status bar’s pending keystroke indicator (shown next to --NORMAL--
in Vim mode) didn’t clear when focus moved to another context, e.g.
hitting g in the editor then clicking the Git panel. The keymap state
correctly canceled the prefix, but observers that render the indicator
never received a “pending input changed” notification, so the UI kept
showing stale prefixes until a new keystroke occurred.
Fix:
- The change introduces a `pending_input_changed_queued` flag and a new
helper `notify_pending_input_if_needed` which will flushes the queued
notification as soon as we have an App context. The
`pending_input_changed` now resets the flag after notifying subscribers.
Before:
https://github.com/user-attachments/assets/7bec4c34-acbf-42bd-b0d1-88df5ff099aa
After:
https://github.com/user-attachments/assets/2264dc93-3405-4d63-ad8f-50ada6733ae7
Release Notes:
- Fixed: pending keybinding prefixes on the status bar now clear
immediately when focus moves to another panel or UI context.
---------
Co-authored-by: Nathan Sobo <nathan@zed.dev>
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Closes#45033
This bug happened because the deletion icon would use the selected entry
index to choose what branch to delete. This works for all cases except
when hovering on an entry, so the fix was passing in the entry index to
the deletion button on_click handler.
I also disabled the deletion button from working if a branch is HEAD,
because it's an illegal operation to delete a branch a user is currently
on.
Finally, I made WeakEntity<Workspace> a non-optional field on
`BranchList` because a workspace should always be present, and it's used
to show toast notifications when a git operation fails. The popover view
wouldn't have a workspace before, so users wouldn't get error messages
when a git operation failed in that view.
Release Notes:
- git: Fix bug where branch list deletion button would delete the wrong
branch
We need to prevent this, since commit message generation did not count
as a prompt in the old billing model.
If users of Legacy Zed Pro customise the prompt, it will count as an
actual prompt since our matching algorithm will fail.
We can remove this once we stop supporting Legacy Zed Pro on 17 January.
Release Notes:
- N/A
Closes#26823
Release Notes:
- Added support for customising the prompt used for generating commit
message in the rules library
---------
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
This PR adds support for collapsing/expanding Git entries with your
keyboard like you can inside the project panel and variable list.
I noticed there is a bug that selecting the next entry when you are on
the directory level will select a non-visible entry. Will fix that in
another PR, as it is not related to this feature implementation.
**Result**:
https://github.com/user-attachments/assets/912cc146-1e1c-485f-9b60-5ddc0a124696
Release Notes:
- Git panel: Add support for collapsing/expanding entries with your
keyboard.
Updates #44089
- Restores the ability to have a partially staged/`Indeterminate` status
for the git panel checkboxes
- Removes the `optimistic_staging` logic, since its stated purpose is
served by the `PendingOps` system in the `GitStore` (which may have
bugs, but we should fix them in the git store rather than adding another
layer)
Release Notes:
- Fixed partially-staged files not being represented accurately in the
git panel.
---------
Co-authored-by: Anthony Eid <hello@anthonyeid.me>
For folders and files basically any selected item in the git panel we
draw a border around it. The issue is that the right side of this border
wasn't ever visible.
In the project_panel.rs file I've saw that the decision was to make the
right side border 2 pixels. And this panel doesn't have this issue, no
matter which side of the dock is selected. So it was a very easy `look
at how we did x do y`.
Before:

After:

I don't think it warrants a release note.
Release Notes:
- N/A
---------
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
The issue is that we aren't consistent in using the same
`panel_focus_border` color across zed.
Might completely fix my issue: #44750
For focused items in:
- outline panel
- git panel
While these:
- project panel
- keymap editor tab
Are actually using the panel_focused_border option.
Not sure if this warrants a release note, feel free to adapt.
Release Notes:
- N/A
Closes#41567
We were using the git panel editor to check the focus where the commit
modal has its only editor.
Release Notes:
- Fixed an issue where commit and amend actions wouldn’t trigger when
using keybinds in the commit modal.
Update the behavior of `git::Amend` to ensure that the latest head
commit message, if available, is always loaded into the commit message
editor, regardless of its state. The previous text, if any, is now also
restored after the amend is finished.
- Update `FakeGitRepository.show` to include a message in the returned
`CommitDetails` so we can assert that this specific commit message is
set in the commit message editor.
- Add default implementation for `FakeGitRepository.commit` and
`FakeGitRepository.run_hook` to ensure that tests are able to run and
don't panic on `unimplemented!()`
- Refactor `GitPanel.load_last_commit_message_if_empty` to
`GitPanel.load_last_commit_message`, ensuring that the head commit
message is always loaded, regardless of whether the commit message
editor is empty.
- Update `GitPanel.commit_changes` to ensure that the pending amend
state is only updated if the editor managed to actually commit the
changes. This also ensures that we don't restore the commit message
editor's contents when amending a commit, before the amend is actually
processed.
- Update `CommitModal.amend`, removing the call to
`GitPanel.set_amend_pending` as that is now handled by the background
task created in `GitPanel.commit_changes`.
- Split the `commit` and `amend` methods from the event handlers so that
the methods can be called directly, as is now being done by
`CommitModal.on_commit` and `CommitModal.on_amend`.
Release Notes:
- Updated the `git: amend` command to always load the latest head
commit message, and to restore any previously entered text in the commit
message editor after the amend completes
Closes#35803
This PR adds tree view support to the git panel UI as an additional
setting and moves git entry checkboxes to the right. Tree view only
supports sorting by paths behavior since sorting by status can become
noisy, due to having to duplicate directories that have entries with
different statuses.
### Tree vs Flat View
<img width="358" height="250" alt="image"
src="https://github.com/user-attachments/assets/c6b95d57-12fc-4c5e-8537-ee129963e50c"
/>
<img width="362" height="152" alt="image"
src="https://github.com/user-attachments/assets/0a69e00f-3878-4807-ae45-65e2d54174fc"
/>
#### Architecture changes
Before this PR, `GitPanel::entries` represented all entries and all
visible entries because both sets were equal to one another. However,
this equality isn't true for tree view, because entries can be
collapsed. To fix this, `TreeState` was added as a logical indices field
that is used to filter out non-visible entries. A benefit of this field
is that it could be used in the future to implement searching in the
GitPanel.
Another significant thing this PR changed was adding a HashMap field
`entries_by_indices` on `GitPanel`. We did this because `entry_by_path`
used binary search, which becomes overly complicated to implement for
tree view. The performance of this function matters because it's a hot
code path, so a linear search wasn't ideal either. The solution was
using a hash map to improve time complexity from O(log n) to O(1), where
n is the count of entries.
#### Follow-ups
In the future, we could use `ui::ListItem` to render entries in the tree
view to improve UI consistency.
Release Notes:
- Added tree view for Git panel. Users are able to switch between Flat
and Tree view in Git panel.
---------
Co-authored-by: Anthony Eid <anthony@zed.dev>
Co-authored-by: Remco Smits <djsmits12@gmail.com>
Buttons and menu items should preferably always start with an infinitive
verb that describes what will happen when you trigger them. Instead of
just "File History", we should say "_View_ File History".
Release Notes:
- N/A
When adding the File History option here, I used the pattern to hide the
option, since that's what another option was already doing here, but I
see other menus in the git panel (`...`) that use disabling over hiding,
which is what I think is a nicer experience (allows you to learn of
actions, the full range of actions is always visible, don't have to
worry about how multiple hidden items might interact in various
configurations, etc).
<img width="336" height="241" alt="SCR-20251203-pnpy"
src="https://github.com/user-attachments/assets/0da90b9a-c230-4ce3-87b9-553ffb83604f"
/>
<img width="332" height="265" alt="SCR-20251203-pobg"
src="https://github.com/user-attachments/assets/5da95c7d-faa9-4f0f-a069-f1d099f952b9"
/>
In general, I think it would be good to move to being more consistent
with disabling over hiding - there are other places in the app that are
hiding - some might be valid, but others might just choices made on a
whim.
Release Notes:
- N/A
Gist is we only need to block the foreground thread for reparsing if
immediate language changes are useful to the user. That is usually only
the case when they edit the buffer
Release Notes:
- Improved performance of large project searches and project diffs
Co-authored by: David Kleingeld <david@zed.dev>
Closes#26649
Release Notes:
- Improved git support for remotes handling. Git will now check pushRemote and pushDefault configurations before
falling back to branch remote.
---------
Co-authored-by: Jakub Konka <kubkon@jakubkonka.com>
We were using `std::path::Path::strip_prefix` to determine which
repository an absolute path belongs to, which doesn't work when the
paths are Windows-style but the code is running on unix. Replace it with
a platform-agnostic implementation of `strip_prefix`.
Release Notes:
- Fixed git features not working when a Windows host collaborates with a
unix guest