Tracking Issue: git integration

[mrnugget]

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: Source control view panel #4367
• A diff view for things that changed: Add a diff view #4523
• Ability to interact with git status gutter and undo changes: Show visual diff / rollback options when clicking changed lines indicator #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

• git blame in gutter, toggle on off - Add git blame #8889
• git blame inline in the editor - Inline git blame #10398
• More information in git blame tooltips
  • Links to PR: Add pull requests to git blame tooltip #10784
  • Avatars: git blame: Display GitHub avatars in blame tooltips, if available #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: History commit #10807)
• ...

[Moshyfawn]

I think #8663 can be added here.

[jaskerv]

Can I add a feature request for a option to have file changed in a tree view? 🙏

[justAdevTV]

I want git blame

[uroybd]

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

[taunusflieger]

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.

[savoygrizzly]

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.

[Ph0enixKM]

We could also have some form of Merge Editor like it is in Visual Studio Code or maybe something even better

[fhamm]

It would also be great if the proposed source control view is compatible with git submodules, similar to VS Code =)

[Moshyfawn]

@mrnugget you might want to link to #10807 where you mention the history milestone.

[mrnugget]

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.

[SomeoneToIgnore]

To soften the wait slightly, I hope to finish and merge #11080 that enabled git hunk diffs browsing in the editor.
It's not a full diff view, but something useful still.

[indrajit-roy]

@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.

[SomeoneToIgnore]

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.

[indrajit-roy]

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.

[SomeoneToIgnore]

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 #8665 (comment)

[mrnugget]

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.

[MarcARoberge]

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.

[ophilli]

It would be really nice to have a "Right Click > Open in github.com" or similar for lines that have a clear git blame.

[mrnugget]

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: #11734

[kevinfaveri]

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"

[SomeoneToIgnore]

@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 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.

[joaodlf]

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

[indrajit-roy-sc]

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.

[cole-abbeduto-particle]

Would love to see a list of remote branches to be able to easily select in the dropdown like Webstorm has 🙏

[SomeoneToIgnore]

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.

project_diff.mov

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:

1. 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.

2. 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.

[Peiffap]

Linking here for visibility: #13511.

[secondl1ght]

Ex-Atom user here waiting for full featured Git integration before I can officially make the switch to Zed. I know you guys can do it! :)

[ninjarogue]

We could also have some form of Merge Editor like it is in Visual Studio Code or maybe something even better

This would give me the final incentive to switch from vscode/webstorm/neovim to zed.

[htor]

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.

It can be confusing with different terminologies, but remember there are more version control systems than git so using generic names in the UI then makes sense.

[szabba]

I see how that's a reasonable thing to do if you want to paper over the differences between VCSes. I didn't get the impression that's a goal for zed (at least in this issue).

[ThatOneCalculator]

Looking forward to this feature 🚀 For me it is a fundamental resource and with it I would be able to start a transition from vscode to zed ✨

It's being worked on, comments like these do nothing but flood notifications. A simple 👍 reaction does the job.

[nxy7]

@524c I'm not contributor, but your comment was useless. Just add thumbs up and don't clutter discussions.

I'm sure there are better places to show enthusiasm than comments that do not contribute anything to the issue. If you care about some software (like Zed) you should also try to make maintainers and contributors jobs easier - don't send comments that do not add anything to discussion, do not send notifications for no reason. After all it's in your best interest that development is as smooth as possible and you probably can imagine that some people need to follow tens of issues at once so such 'enthusiastic' comments add up and eat time that could otherwise be spent more productively.

[chrisdigital]

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: #11734

Is this a current view one is supposed to be able to view? I don't see anything in the project view.

[mrnugget]

Is this a current view one is supposed to be able to view?

You open it with editor: toggle git blame

[NiloCK]

Can Stage Hunk get added as a command in the command palate and in the context menu for a hunk?

Behavior similar to VSCode's Stage Selected Ranges

This will maybe be less popular, but I'd also love a Stash Hunk command in the same contexts.

Apologies if this is a dupe, but I didn't find it.

[Angelk90]

@mrnugget : What Milestone have we reached?

[mrnugget]

Milestone 1

[gavinmorrow]

Would it be possible to make the files in the tab bar also show if they are new/modified (the same way they are in the project files)? I keep finding myself looking for that.

EDIT: nevermind, I found the setting. (tabs.git_status)

[lionel-]

Ideas for committing while doing collab/pairing work:

• Option to automatically add Co-author lines to commit messages for people connected in the session.
• Allow all participants to commit. If they initiate a commit, they become "first author" and others get a Co-author mention.

[Angelk90]

Milestone 1

@mrnugget : Where can I find the Milestone developments, on https://github.com/zed-industries/zed/projects?query=is%3Aopen
I can't find anything?

Then the first Milestone goals are already all complete for git.

[mrnugget]

Not sure what you're after, but we didn't tag all issues/PRs for this milestone. It was a manual process to check off the checkboxes here.

[Angelk90]

Not sure what you're after, but we didn't tag all issues/PRs for this milestone. It was a manual process to check off the checkboxes here.

@mrnugget : Where can I see the milestone processes?
For example, taking a repository that uses correctly, CE you can see in the current milestone which are todo, in progress and complete.

[mrnugget]

Like I said, we didn't use that. I just created that issue you see at the top and checked checkboxes off manually and linked to the relevant PRs.

[baldwindavid]

For those that like TUIs, I use lazygit from within Zed and perhaps that can tide over some of those waiting for builtin functionality.

The general idea is to set a keybinding that opens lazygit in a center terminal as another tab...

  {
    "bindings": {
      "cmd-g": [
        "workspace::SendKeystrokes",
        ": new center terminal enter lazygit enter"
        
        // Note: non-vim users would have to do something like below to open the command palette...
        // "cmd-shift-p new center terminal enter lazygit enter"
      ],
  },

I do use and enjoy the already builtin blame features in Zed, but not sure I'd stop using lazygit even if advanced builtin functionality were to exist. Maybe a fancy UI for tricky merge conflict resolution, but that would be way off in the future and I tend to crack open Sublime Merge for that anyway.

[reslear]

Maybe a fancy UI for tricky merge conflict resolution, but that would be way off in the future and I tend to crack open Sublime Merge for that anyway.

By the way, maybe someone knows how to implement the function
“Open repository in Sublime Merge” as in https://github.com/giovdk21/vscode-sublime-merge ?

---

Ok, my solution:

1. Setup smerge

sudo ln -sv "/Applications/Sublime Merge.app/Contents/SharedSupport/bin/smerge" /usr/local/bin/smerge

2. Add task "zed: open project tasks" :

[
  {
    "label": "Open repository in Sublime Merge",
    "command": "smerge $ZED_WORKTREE_ROOT",
    "reveal": "never"
  }
]

3. "task: spawn"

Waiting for zed api to add items to the context menu or button in the footer

Credit:

• https://gist.github.com/SuryaElite/58ff27c474accd31dbd91545ee0d3620
• https://www.sublimemerge.com/docs/command_line
• https://zed.dev/docs/tasks