zed
zed copied to clipboard
zed-industries
Tracking Issue: git integration
Problem
Our current git integration is very minimal. What we have:
- showing current branch, selecting branches
- showing git status in gutter, until changes are staged
- showing git status in project panel
- navigating to previous/next hunk
Many users are asking for more git integration:
- A "git panel" similar to the VS Code one: https://github.com/zed-industries/zed/issues/4367
- A diff view for things that changed: https://github.com/zed-industries/zed/issues/4523
- Ability to interact with git status gutter and undo changes: https://github.com/zed-industries/zed/issues/4630
Goal
Build a 0.1 of git integration that fixes immediate pain points and stops users from leaving Zed to go to GitHub, GitLab, or another editor to use a git feature.
The most common git interactions should be doable inside Zed: committing, staging, unstaging, viewing diffs, ...
They should allow keyboard-only workflow.
Current status
Work on git integration is paused at the moment, since we're spread too thin on a lot of other projects.
Roadmap
Ranking here very subjective and based on personal pain points.
Milestone 1 - git blame
- [x]
git blamein gutter, toggle on off - https://github.com/zed-industries/zed/pull/8889 - [x]
git blameinline in the editor - https://github.com/zed-industries/zed/pull/10398 - [x] More information in git blame tooltips
- [x] Links to PR: https://github.com/zed-industries/zed/pull/10784
- [x] Avatars: https://github.com/zed-industries/zed/pull/10767
Milestone 2 - git diff
- Support diffs
- Allow opening diffs from git status view
Milestone 3 - git status & git commit
- git status view
- see: working directory is clean or dirty
- see: untracked, unstaged, staged files
- do: stage/unstage files
git commit- triggered from git status view
- opens git commit message
Things we have to do
- Support opening sub-folders (or single files) of git repositories
Milestone ...
- History (see: https://github.com/zed-industries/zed/issues/10807)
- ...
Can I add a feature request for a option to have file changed in a tree view? 🙏
Conventional commit support in git commit will be great.
Alternatively, we can allow plugins to take care of these things like this one: https://marketplace.visualstudio.com/items?itemName=vivaxy.vscode-conventional-commits
Would be nice if you work in a folder below the git root and get ask if you want to locate the repo (as it is done in vscode). Currently if you are not opening the git root, but a sub directory git support is not enabled.
Just wanted to drop in there that the new git integration should allow for multiple git's inside an open folder, I like to be able to have my container open so I can work on multiple services at the same time.
We could also have some form of Merge Editor like it is in Visual Studio Code or maybe something even better
It would also be great if the proposed source control view is compatible with git submodules, similar to VS Code =)
@mrnugget you might want to link to #10807 where you mention the history milestone.
Update here: we're going to pause work on the git integration for a few weeks, since we have a lot of projects going on right now — Tasks, Linux, remoting, AI — and are spread a bit too thin. Since we've reached a good pause-point here (just checked off Milestone 1), we'll pause work on git, focus on other projects for a while and then come back to git integration once we've finished other projects or reached significant milestones.
To soften the wait slightly, I hope to finish and merge https://github.com/zed-industries/zed/pull/11080 that enabled git hunk diffs browsing in the editor. It's not a full diff view, but something useful still.
@mrnugget Can the community contribute to this? It would be nice to see the approach and design hosted somewhere so that interested folks can help speed up the process. I myself would like to switch to Zed permanently and am more than willing to help ship this asap. This is a huge and the only blocker for me right now.
Of course it can, this is the whole point of Zed being open source.
I would suggest starting from something small-scoped, come up with the proposals and (ideally) some design drafts to discuss it first — defining the right chunk of work is the most complicated first step here, it seems.
Be wary that some subtasks of this "epic" are quite hard, e.g. the whole "show a two panel diff" story will require writing something like https://github.com/zed-industries/zed/blob/main/crates/editor/src/display_map/inlay_map.rs but for git things.
Of course it can, this is the whole point of Zed being open source.
I would suggest starting from something small-scoped, come up with the proposals and (ideally) some design drafts to discuss it first — defining the right chunk of work is the most complicated first step here, it seems.
Of course. Just want the existing specs to be highlighted so that anyone taking this up doesn't re think anything that's already decided on.
I suspect there's nothing well formed, covering the entire integration task, only a few ideas split between people (right now I work on something related to diffs, there are some design drafts, etc.). See also notes in the https://zed.dev/channel/git-5484 channel for a rough plan on how to move it forward.
So, any proposal could easily be better than the current state. I would not take too much of an effort to draw detailed designs, as @\iamnbutler might have better ideas, but otherwise anything is free to be picked up due to https://github.com/zed-industries/zed/issues/8665#issuecomment-2074561256
Anyone's free to help, sure, although I would caution against picking up one of the bigger items — git commit view, git status view, git diff view — since they require a lot of design and conceptual thinking up front on and the Zed team does have opinions on all of them, we just need to find the time to get to it.
May I suggest a small increment for the git diff view? With the help of the hunk feature recently merged, we could add a "filter" to only see in the project panel the files with the git-status changed. This way we could get a list of all files and if we want to see the diff, we could use the expand all hunks feature for now.
It would be really nice to have a "Right Click > Open in github.com" or similar for lines that have a clear git blame.
It would be really nice to have a "Right Click > Open in github.com" or similar for lines that have a clear git blame.
@ophilli: You can already click on the commit sha here to open it on the code host:
But I also just opened this PR: https://github.com/zed-industries/zed/pull/11734
May I suggest a small increment for the git diff view? With the help of the hunk feature recently merged, we could add a "filter" to only see in the project panel the files with the git-status changed. This way we could get a list of all files and if we want to see the diff, we could use the expand all hunks feature for now.
hey @mrnugget this seems a really low hanging fruit, allowing to filter files in files view by git status being modified. Is anything we can expedite quickly? Would really help with easily going to files that got modified in a "stable sidebar"
@kevinfaveri
I would argue about really easy, as the devil is in the ergonomics details.
The main line of questions to your proposal is: what to do with those filtered items in the project panel? Given most other tool experience, there should be click listeners, showing the diffs somewhere, how Zed is supposed to display this and how all those items are interacting with each other?
My current idea is to reuse current git hunk diffs (inline diffs) functionality, and show all changed places of a singleton buffer inside of a multi buffer (as for search results: we do not show the entire file with multiple matches inside, but rather show take excerpts around the matches and show those in a multi buffer), with the diff hunks expanded always (?).
As a first attempt, I will use a single multi buffer for all file entries, and get a project panel to show only the entries, related to excerpts of that large multi buffer — those will be all files that have some git changed metadata (modified/added/removed/conflict/etc.). Project panel now only shows real files, but that might not be very ergonomic for large files with many changes, so some fake entries might be required. And whatever the entries are, they still have to support previous project panel features, but for a companion multi buffer now:
- select a corresponding file when multi buffer's selection changes, also support a reveal action
- scroll to an excerpt when clicking a project panel entry (instead of opening the editor for the file as we only do now)
- directory expands/unexpands and fold/unfolds
Currently, I have a https://github.com/zed-industries/zed/compare/main...kb/buffer-panel branch that, while not related to the git diff explicitly, allows to have a companion "project panel" for any generic multi buffer, with the practical emphasis on the project search view.
Moreover, this is the first time in project panel's code history to add some filters on top of the current "all files in the project"-only approach, and besides all the above, it has to deal with performance implication — we can definitely do better than the branch does currently.
So, I think I'm getting there and the road is interesting and possible conceptually. A good amount of work and wiring has to happen along the way though, so maybe I'm not over by the end of June but who knows.
I would recommend the Zed team (or anyone building software like this) to take a look at the way Jetbrains handles git integration. From basic functionality like commit/pull, to the amazing log interface, as well as the individual file history feature that fits into the git log UI. Even small things like being able to quickly open a file+line number in GitHub/Gitlab. Jetbrains has completely nailed their git integration, it's a fundamental aspect of my productivity and very hard to move away from.
edit: in fact, this thing is so good, the community is asking for a standalone git client from them: https://youtrack.jetbrains.com/issue/IJPL-72504/Make-git-client-a-standalone-app
Completely agree with @joaodlf
If Zed can nail JetBrains' level Git integration and at the same time keep the memory consumption close to what it is right now, it will be the hugest win in the world of IDEs.
Would love to see a list of remote branches to be able to easily select in the dropdown like Webstorm has 🙏
As a counterpoint: I personally avoid most git-related features in IntelliJ like the plague - with the exception of 3-way merge. The UI is complex and confusing, I recall operations having non-git names - I've learned git first, IntelliJ second, so that's beyond unhelpful. I've found that when I use VS Code I use the provided git integration much more readily.
As a heads-up, the preparation phase for the project diff view is forming: https://github.com/zed-industries/zed/pull/12637
I plan to test it internally and release around Zed 0.141 , meanwhile iterating on top of this feature with more git-related changes: the new feature allows to show a multi buffer with all non-staged changes in the project, backed by the outline view. If that prototype shows good signs, we can start a (somewhat) long road towards a proper project git diff view:
- add a way to show staged files similar to unstaged ones
- show conflicts properly
- potentially add more entries (not just outlines) below the changed files
- consider adding a commit input + pull/push buttons under the outline tree, similar to what Intellij has?
- somehow improve the egonomics around git diff hunks, maybe inlining them inside another GitMap inside the Editor.
- ... whatever else along the road
An interface similar to vim-fugitive could be cool. I'm trying to use zed as an alternative to neovim (testing it mostly).
I'm also coming from Neovim for testing zed (very smooth so far!) and I second @Wragdan's suggestion of investigating fugitive's design. What I particularly like is that it really emulates 3 of the most common git commands you'll find across all levels of experience, git status, git add and git commit. It even looks very similar to git status in it's UI. However there's a huge amount of functionality hidden in the keymaps/right-click that is not needed in 99% of usage.
Seconding @szabba's points, I've had to teach juniors about basic git things and somehow through jetbrains, it makes some very simple things drowned in several popup windows and non-labelled and confusing buttons.
Just as a short illustration:
There's a simple stage and unstage on the right I can pop up, preview file hunks when hovering over a file. Adding a file or hunk is straight forward by hitting a on either the file/hunk and when I'm ready, I can hit ,gc and just write the commit message, collapsing the whole side bar and letting me get back to the main editor view.
As a counterpoint to fugitive, it's aimed at keyboard centric users. It may not play well from a click-based perspective in design space.
A small update on the project diff side: there's a prototype branch https://github.com/zed-industries/zed/compare/kb/project-diff?expand=1 which adds an action to create a multi buffer with all git changes Zed can detect now (modified files only, no staged changes) and maintains buffer's excerpts' order as in the project/outline panels with the FS tree.
https://github.com/zed-industries/zed/assets/2690773/41d7947e-b738-4d30-a868-975d6c333ead
As the video tries to show, it reacts on the external FS events and auto expands all new changes in the excerpts. The diff display based on displaying the expanded git hunks which is inconvenient for browsing large modified hunks — to mitigate that, the multi buffer could be split into a new pane, the PR does not aim to add any side-by-side multi buffer diff view.
I do not think it's ready to be merged at the current state:
- Zed does not notice "added" and "deleted" files at all, which looks quite confusing (there's also no information about staged changes and conflicts, but those are missing everywhere in Zed, while all other additions and deletions are shown)
This might be relatively tricky to add though, as would need to create "fake" deleted buffers and store them somewhere (in the same diff view, presumably) — but even this PR would not include this, there should be a plan on how to add these and what are the complexities related.
- Overall, new multi buffer experience feels a bit below regular Zed multi buffers:
- it is slow to appear for certain changes in certain projects — presumably, due to waiting for all changed buffers to open, but maybe there's more to fix. Also, the clone of the buffer, appearing during the split, should clone the previous state instead of re-collecting it (updates are harder to do this way and might be fine for now to keep doing separately on each split)
- there are some small (?) bugs in the update code — it mostly works, but seem to sometimes skip the changes highlights too aggressively if those are on the edge of the excerpt; maybe some extra changes are displayed too? More refactoring and testing is needed on that front. Most of these issues appear due to excerpts being rather narrow — changes on the edges need excerpts to expand in order to show the entire change highlight, and either we should do that automatically or, at least, enlarge the default diff excerpts' size for now.
- there's a certain level of flickering that happens periodically during edits, esp. on the very first one (but not on the 2nd or 3rd change, which is peculiar) — while some level of it is inevitable during the current way Zed renders the excerpts, syncing them after the rest of the editor is painted, but here it seems that some invalidation might be to blame too, as these do not flicker always — either the editor/element.rs code or the diff panel code needs a check, the latter has a few TODO related to invalidation.
- the whole UI is not finished yet — diff multi buffer's tab shows something copy pasted from the diagnostics now, and, ideally, should have a notable button in the status bar (similar to diagnostics, something dynamic with +20/-100 diff stats). Outline panel better show something different than outlines.
All this does not seem hard, but still requires a significant amount of work and concentration which I do not have now — so, I will pause with this change for now and use the bits of my spare time on improving the outline panel first. Now, I have all code needed to prototype new items inside, not just the outlines, so the project diff panel will benefit from this work nonetheless.
On the grand scheme of things, side-by-side diffs for this part seem to be the hardest task and won't appear before singleton buffers' side-by-side diff is implemented first. I have ideas on how to prototype this for singletons already, and it seems that the only complexity is the scrolling (and the scrollbar in general), so maybe that happens before the project diff is merged in its first form.
Meanwhile, if anybody is interested enough to pick this up and fix the issues aforementioned — welcome a lot. I'm also curious to get some feedback, if the current state (modulo bugs and performance) is good enough for the start, I might consider merging it first without more git entities supported.
Linking here for visibility: https://github.com/zed-industries/zed/issues/13511.
