RFC for Interactive Log View #1419
Conversation
smashwilson
added
work-in-progress
feature request
| * The `github:log` command in the command palette. | ||
| * An "Open Log" menu item in the context menu on the recent commit history. | ||
|
|
||
| When launched, the log view pane uses WebGL to render a 3D model of your commit graph. |
There was a problem hiding this comment.
@smashwilson Do you have an example of a 3D log visualization or is it something that only exists in your imagination. 💭
There was a problem hiding this comment.
Totally and completely in my head 😆
If I get a chance, I might start playing around with a prototype for this to see if it's viable.
There was a problem hiding this comment.
On a semi-related note, I met some guys who made a git branch viewer for the hololens (it would display the branch graph fixed in space). So I guess that's one realization of a 3D log visualisation
|
|
||
| ## Motivation | ||
|
|
||
| Visualizing the commit graph is an important tool for learning git. A live view of the commit graph can inobtrusively help git newcomers form the correct mental model for commit graph operations (branching, merging, rebasing). |
|
This sounds like a really interesting idea for seeing things immediately around where you are right now, but how will it handle large repositories? hundreds of commits? thousands? millions? |
|
Scaling up and still being useful is the big challenge in my mind, yeah - to the point that I don't think any existing tool, including I was hopeful that these would help:
But it's a big problem which will likely have a long tail of trial and error. I was hoping to track down a few example repositories (torvalds/linux, etc) that would push the limits and see how quickly performance and understandability degrade. |
A while back I was playing around with a log view, well it's not really a typical log view, but more a Git/GitHub navigation or time machine. The inspiration comes from how you navigate through time when setting a date, like this date picker on iOS:
Instead of showing a chronological, never-ending list of commits, it would group them in parallel by versions > PRs > commits. This would let you navigate in small or big steps. It also gives you a better understand what commits "belong" together, instead of having the "guitar hero" lines, it would "show me all PRs from this version" or "show me all commits from this PR".
If you commit straight to master, then the single commit would show up in the 2nd column (since there is no PR). If a repo has no versions and no PRs, then I guess it would just show the long list of commits. The grey highlight is where your current HEAD is. The faded PRs/commits above show what you haven't pulled yet. With auto-fetch, it would let you know if your team members made new PRs/commits and you know what will happen if you pull. You can "pull" by simply double clicking on a faded commit/PR. This lets you "move forward in time" in a much more controlled way than just pulling all the changes at once. You can also go back in time by double clicking on any version, PR, or commit below your "HEAD line". Single-click could show a preview with a diff and more infos. Not sure if moving back in time should do a reset hard? Maybe to make this possible at any time, it could create a temporary worktree. Then you can move back in time without having to commit and push first. You could see how code used to be, run tests, copy delete code or so and then just a quickly fast-forward again and your changes are still there. Clicking above
Sorted by recent changes. So it gives you a hint what might come next. Also handy to quickly checkout and test/contribute to a PR. Here a more compact version that might even fit at the top of the tree view. You could drill down and either the versions, PRs or commits column would expand:
Be able to navigate between files AND history in the same place might be handy. Less switching between panels and you get to see files getting added/removed as you time travel. Each column is scrollable, but the history "section" could also be resizable or collapsable to just a single item (if you really want to save space). Haven't really thought about stuff like merge, rebase, cherry-pick, squash, rename etc. Maybe by drag&drop? Anyways, since this goes into a different direction, it probably should be its own RFC. Also, the two approaches don't have to be mutually exclusive. We'll just have to fight over priority. 😜 |
|
Is there a reason to have this here instead of in the git package? The reason I ask is it applies equally (except for PR features) to git projects hosted elsewhere (or not hosted at all), and I'd really like to see this usable for github enterprise (we're still not there yet with this package). |
Yes. There is no git package 😉 The package in this repository includes both git and github panels. |
| * Each commit is rendered as a sphere, possibly with adjacent text (see below). | ||
| * A line joins each commit to its parent. | ||
| * Refs are rendered as rectangular tags attached to the relevant commits. | ||
| * When a remote is present, commits that are not reachable from any remote ref are rendered _[TODO]_. Commits that have been fetched but are not reachable from any local ref are rendered _[TODO]_. |
There was a problem hiding this comment.
There's basically 2 pieces of information you want to convey (preferably visually and at a glance) here:
- Local, remote, or both
- which remote(s)
My initial thought (assuming this view has a strong sense of up and down) is that local only commits are rendered as a pyramid (pointing up, which mildly indicates push). Remote only commits are rendered as an inverted pyramid (pointing down, which mildly indicates pull). Any commit that is both local and remote will be a sphere.
My idea for indicating which remote/remotes a commit is part of is to render an icon within the pyramid/sphere for each remote a commit is part of. We could use a house icon for origin, and a wavy (diagonal upwards) icon for upstream. Maybe basic geometric shapes (square, circle, triangle, star) for any other remotes. Local in this case is signified by the absence of an icon, or possibly by a computer.
If you give each remote its own color, then you could mix the colors to determine the color of the sphere/pyramid. Maybe local only is gray, origin is green, upstream is blue, etc. Then upstream and origin would be cyan/teal (mix of blue and green), etc.
There was a problem hiding this comment.
This scheme works well with the levels of detail. Highest level of detail lets you hover the remote icons to see the names for the remotes, or maybe even pops them out to the left side with names. Medium level of detail lets you see the icons, but maybe smaller, or maybe only the first remote. Low level of detail has no icons, but retains the shape and color, so you can visually see if there's a "far away" commit that hasn't been pushed yet.
| When launched, the log view pane uses WebGL to render a 3D model of your commit graph. | ||
|
|
||
| * Each commit is rendered as a sphere, possibly with adjacent text (see below). | ||
| * A line joins each commit to its parent. |
There was a problem hiding this comment.
parent(s)*
merge commits have two (or more, in the case of an octopus merge) parents.
There was a problem hiding this comment.
Merge commits actually have as many parents as needed. Two is just the most common.
Starting to write down my thoughts around this. Highly incomplete.
⚡ 🎨 rendered 🎨 ⚡