Git - create git graph visualization

[GIT-MDW]

Type: Feature Request

While working with git graphs, I utilize both vscode and webstorm to determine which one is best, and I believe webstorm's git graph is effective right now.

Webstorm has a free git tool that we can use, but we must install an extension for vscode to use it. The best extension is git graph, but it costs money for extra things and isn't very versatile. Can it be made better to have one built in with annotations (like in webstorm git blame , you can check it in webstorm ) and so on..?

vscode git graph https://marketplace.visualstudio.com/items?itemName=mhutchie.git-graph

VS Code version: Code 1.77.0 (7f329fe, 2023-03-29T10:02:16.981Z)
OS version: Windows_NT x64 10.0.22000
Modes:
Sandboxed: No
Remote OS version: Linux x64 5.10.16.3-microsoft-standard-WSL2

For example there is good a program that can be considered as well as alternative, but 100% you need to implement in vs code

This one has more functions and for now is the best I think

https://www.sublimemerge.com/

[Keavon]

Git Graph is the single best thing ever to happen to making Git accessible. It single-handedly taught me Git from it being a complete mystery to being perfectly intuitive. It's also such an efficient and useful tool that I consider it my "home page" in the VS Code editor.

However, it is no longer maintained at all (the creator has been offline for years).

But it is so well designed, so popular, so useful, and still manages to be a minimal and unopinionated approach to visualizing a repo's Git commit history, that I strongly believe it absolutely deserves to become the blueprint for VS Code's built-in Git history viewer. This would make Git profoundly less confusing for millions of people. And it would act as a perfect complement to the existing Source Control panel that's already built into VS Code.

VS Code team, please consider reimplementing the core design of Git Graph straight into the default VS Code experience! Literally millions of people are counting on it (Git Graph has over 8 million installs and a 5.0/5.0 rating because it is so adored— making it the #2 most highly rated extension in the entire VS Code marketplace, only behind an extension for a color theme).

[otdavies]

I want to second @Keavon's point here. It is the best git extension available. It is great for code review and properly represents the flow of your git history without any biases. Please please make this a core part of VSCode.

[isaacsando]

I use this daily to review my git branches. I would love to see this as a core part of VS Code!

[piradata]

hello, i also would love this feature, there is no way to review git commits without the git blame and git graph extensions

[MuTsunTsai]

Absolutely second @Keavon 's proposal. We all need that.

[Guddi11]

Same here. It’s too bad git graph is not further maintained at the moment. To implement its core functionality would put the use of git in vscode through the roof.

[romansh]

+1, I'd like to see it as a core functionality for VS Code.

[AlexMarlow25]

It would be nice to see this feature as the main functionality in VS Code! This is one of the key features that still forces me to use WebStorm with VS Code.

[AndreHorst]

No doubt this extension shall be an essential core feature of VSCode.

[Patta]

+1

[imagryesweid]

Invaluable for large scale repos

[pdicerbo]

Essential to my everyday work!

[Jibbajabbafic]

This is an absolute must have extension and I always recommend it to new starters in my team, so having it directly integrated and maintained would be a huge benefit to the community.

[pascal456]

support this idea, +1

I use Git Graph on daily basis.

[apitofme]

Not sure what to do about this but I found that there is a (presumably "illegally" forked / cloned / reverse-engineered) version of the O.G. Git Graph that has been published to the (OpenVSX) marketplace, going by then name Git Graph Plus.

1. This version links to a fully permissive MIT license with notably different copyright details.
2. It doesn't even try to hide it's fraud, given that it still links back to mhutchie's repo where (or course) the original restrictive license still exists.

Whilst first-party functionality is highly desirable and I am hopeful of this campaign's success, in the meantime may I also note that there is a new extension available in the marketplace which aims to provide a fully and permissively free, maintained and fork-able alternative to Git Graph called "git-log--graph" by phil294 (which is in both the Microsoft and OpenVSX marketplaces).

So for those interested / inclined you can support this new project here?

---

(Note: I have no affiliation to any projects mentioned!)

Additionally, since it is unrelated to the MS Marketplace (where it does not appear to be listed) I have reported the fraudulent extension to the maintainers of the OpenVSX marketplace (i.e. Eclipse Foundation)

[GIT-MDW]

For example there is good program that can be considered as well as alternative, but 100% you need to implement in vs code

This one has more functions and for now is the best I think

https://www.sublimemerge.com/

[CDboyOne]

+1

[gamesun]

+1

[Cube707]

+1

[SuperDino484]

+1

[piradata]

guys, stop with the +1 on comments, just a 👍is enough

[bvandevliet]

I think this is related: #219953
Seems to me they're trying to implement a git graph in the source control panel, but it's experimental at the time of writing and doesn't work well yet. But it might be something to check out and keep an eye on.

[Fydon]

The new functionality shows changes in the current branch and possibly the base branch (read here to see more) and is an experimental feature in version 1.19. GitLens's Commit Graph would provide more what I think is being asked for, although not built into vscode. However the Commit Graph is a Pro feature (free for public repositories but requires a license for private).

[Keavon]

GitLens's Commit Graph would provide more what I think is being asked for

GitLens is hideously bloated to the point of total uselessness. There's a reason it has only a 3.7 star rating. Git Graph, with a 5.0 star rating (universally beloved as the highest rated non-theme extension of all time), is elegantly minimal and is the main point of interest amongst most people voting for this issue. I really need to stress that Git Graph, from a UX perspective, is very near the global maximum in the space of all possible UX designs for a Git repo visualization. It should be copied shamelessly.

[bvandevliet]

The new functionality shows changes in the current branch and possibly the base branch (read here to see more) and is an experimental feature in version 1.19. GitLens's Commit Graph would provide more what I think is being asked for, although not built into vscode. However the Commit Graph is a Pro feature (free for public repositories but requires a license for private).

You're right it shows changes only. However the fact vscode now has a sort of git graph implemented (though very limited) gives me hope that they might extend on that in the future making it a full featured git graph. I mean part of the work is already done right. :)

[Keavon]

Some seemingly good news mentioned in the 1.93 release notes (specifically the last sentence, which I've bolded):

Source Control Graph view

Based on user feedback, we have moved the history graph that was enabled last milestone from the Source Control view into a new view called Source Control Graph. This reduces the information overload from the main view and enables you to hide/collapse/move the new view as you see fit. This also lays the foundation for a full-featured history graph.

---

@lszomoru Would it make sense to update the triaging of this issue in any way to reflect that intention? By the way, I'd also like to volunteer to be involved in any kind of design, use case determination, feedback, etc. if this moves forward and that's something your team would find useful. (My background is in product design and UX, and I have lots of thoughts regarding Git visualizations that I'd be most happy to share.) Thanks for building towards this, by the looks of it.

[lszomoru]

Thank you all for your interest in this feature request and for your patience. While in VS Code 1.93 we did ship the new "Source Control Graph" view I did not want to update this issue just yet as the first iteration was very limited in functionality.

Since we shipped VS Code 1.93 we have been heads down polishing both the user experience as well as adding new functionality to the Source Control Graph view. Please download VS Code Insiders (1.94), give it a try and let us know what you think.

As far as feature parity with extensions I would like to set clear expectations that we will focus on basic functionality and not provide all feature that are available in extensions as we want extension authors to continue to innovate in this space and continue to foster a vibrant extension ecosystem.

@Keavon, thank you very much for your offer. The best way to engage is to download the latest VS Code Insiders release, try out the graph, and share any feedback that you have around the UX in this issue. We are still polishing the UX so any feedback that you have will be appreciated. Thank you!

[bvandevliet]

@lszomoru If functionality will remain basic and extended functionalities are intended to be added through extensions, I'd suggest that the source control graph view should at least have a rich API to extend on it, e.g. context menu's, etc ;)

[lszomoru]

I'd suggest that the source control graph view should at least have a rich API to extend on it, e.g. context menu's, etc ;)

That's the plan.

[Cube707]

@lszomoru I just tested the insider build and really like the work.

I thing I noticed: there seems to be a problem when showing all, where commits are not added to the view according to their date but in some other order. for example:

this image taken from the GitGraph extention shows the feature-branch in between the two tags, where it last updated:

In the new view the branch is missing in between the Tags:

Instead it shows up much further down:

[lszomoru]

Thank you very much for the feedback. The "Source Control Graph" view is currently using topological order of commits (--topo-order). This order was created specifically for rendering commits in a graph as it makes the graph easier to read as it avoid interleaving commits. In the future we will surface this as a setting so that users can choose the order that is being used.

[Cube707]

In the future we will surface this as a setting so that users can choose the order that is being used

Making this configurable seems like the best solution 👍

[bvandevliet]

I've been testing v1.94.0 a bit and I really like the direction this is going to, great work!! 👍

There's just one last thing that is holding me from completely switching from the good ol' git-graph extension to this new built-in source control graph. That is that clicking a commit in the source control graph shows all diffs expanded at once, while in the good ol' git graph extension the graph expands showing the files that have changed, then by clicking one of those files it would show just that diff. See my paint skills below how this could look like if implemented into the source control graph.. ;)

Might this be something that others also like to have, or is it just me ;p? Though, I'd already be satisfied if there's a setting that allows the diffs to always appear collapsed by default (instead of expanded and having to click the "Collapse all diffs" button each time).. :)

[T-256]

Though, I'd already be satisfied if there's a setting that allows the diffs to always appear collapsed by default (instead of expanded and having to click the "Collapse all diffs" button each time).

👍 Or just similar file tree feature from github:

[Cube707]

I also second @bvandevliet.

I especially find it strange that clicking a file with open changes and wanting to see the changes made by a commit results in two different types of views (one showing multiple files and one only showing a single file). While they are only slightly different I believe that showing identical views would and having a file-tree in the new source-graph would feel more consistent.

[probitcarwyn]

Being able to revert a commit from the graph view would be really handy. Typical workflow:

• Make a commit.
• Realise it's on the wrong branch (usually main).
• Use the graph to create a branch from the parent.
• Cherry pick the commit onto the right branch.
• Can't do the "undo" of the commit on the wrong branch from the graph view.

Obviously you can do this in other ways, but given the other actions are possible from the graph view, it would be nice to be able to do the last step there too.

[Cube707]

The same is true for rebasing onto a branch.

• checkout a feature-brnach
• right-click in the graph-view -> "rebase current branch here"

this would be very handy

[bvandevliet]

May I summarize this as reference and add some more? :)

• Make browsing diffs more usable / user friendly (2407072695, 2434701422, 2435036201).
• Ability to select two commits and view the diffs between those.
• Add option to sort the commits in the graph based on their datetime (2363205011, 2366732569).
• Also show stashes.
• Extend context menu on right-click on a commit, tag, branch or stash, (depending on the context of what was clicked):
  • Checkout branch (2435036201)
  • Rename branch...
  • Delete (remote) branch...
  • Push branch...
  • Pull into current branch...
  • Merge into current branch...
  • Rebase current branch on branch... (2435036201)
  • Rebase current branch on this commit... (2435036201)
  • Reset current branch to this commit... ("undo" in 2434940874?)
  • Revert this commit
  • Delete (remote) tag...
  • Push tag
  • Apply stash
  • Pop stash
  • Drop stash

[Cube707]

It would alternatively be helpfull to get feedback on what won't make it into the official version, so that work on extensions for these features could begin

[ADTC]

Is there any existing issue for this problem? I can't find any, but maybe I'm not using the right keywords in my search...

Edit: Below has been posted as issue #232947

When viewing the diff of a commit from the graph, or when viewing the full diff of changes or staged changes, "moved or renamed" files are not shown as such, but they are shown as separate delete and add operations.

Note: I know that a Git commit has no notion of "renames" but most diff tools (including git diff) use a similarity index to convert any "delete+add" pairs into "rename/move" if they have high similarity. Seems like VS Code diff is completely refusing to do this (even with 100% similarity).

Am I missing a config, or should I open a new issue?

Edit: Below has been posted as issue #232948

Another issue: the combined diff view doesn't indicated whether the file was added, changed, deleted, moved etc. All files look the same especially when collapsed. It doesn't show the change ratio or +/- character count either. I hope we can bring in the basic features of GitHub diff into VS Code diff as a reference.

[lszomoru]

@ADTC, could you please file separate issues for this so that I can look into it? Thanks!

[laterz]

其实，Visual studio有这样看起来很好用的Git可视化功能，希望在VSCode中也开放下！

https://learn.microsoft.com/zh-cn/visualstudio/version-control/git-browse-repository?view=vs-2022

In fact, VisualStudio has such a very useful+beautiful GitGraph function. I hope it can be implemented in VS Code!

[aurexav]

In fact, visual studio has such a very useful+beautiful GitGraph function. I hope it can be implemented in VS Code!

Please don't post such screenshot here. There were already a lot of people mentioned such extensions. It will just make thread long and hard to read.