vscode-git-graph
vscode-git-graph copied to clipboard
mhutchie
Customizable branch priorities
(Quick note: "channel" refers to the columns that branches can be in - comes from the definition: "a groove or furrow")
Prioritising Specific Branches to Keep Them Left
Issue Number: #207
Summary of the feature: Assign priorities to branches, and have all branches be rendered in a sorted fashion, where the prioritised branches are first.
Description outlining how this pull request resolves the issue: A lot has occured to make this pull request happen, specifically, a large rewrite of Git Graph's graphing types (Branch and Commit). Additionally, a fair few other types have been changed/removed to simplify the codebase.
I've tried to keep the visualisation as close as I could to the original representation. I struggled fighting with VSCode to do side by side comparisons, but I ended up eyeballing some before and after screenshots and it doesn't look too far off...
What this feature aims to do is:
- Provide a capability allowing users to prioritise certain branches to the left-most "channels" (columns)
- Allow users to specify which branches should be prioritised on a per-workspace basis (ie, each repo can have different priorities)
- Allow users to specify local and remote branches as priorities as a setting (
git-graph.priorityBranches)
Where this implementation needs tweaking:
- The rendering algorithm works, but it can look a bit chaotic depending on the repository. ~~(See below with no left-gap filling)~~
Where this implementation lacks:
- [x] This has been tested on a variety of repos including simple, complex(?), and
git-flow-based repositories (images below), however, there are many situations which haven't been tested - [x] The rewrite was completed over a week, with significant gaps of time in between, so it's likely that there may be errors or unnecessary code present
- [ ] The line segments are not simplified, like in the original Git Graph (this could be implemented, but depends on the necessity - such as serious performance improvements)
- [x] The line rendering is not identical to the original algorithm, however, it ensures that branches push rightward as soon as possible, and push back leftward as late as possible
- Since the line rendering is not identical, it's likely that users will need to adjust to the new graphical representation
- [x] This implementation doesn't fill empty gaps to the left, so you'll see a pyramid of branches as more are added (picture example below)
- [ ] In some situations, it might look like two deleted branches follow the same pathway but that's just a collision of the lines. This seems to happen when a new branch (B) is made using a parent prior to the start of a deleted branch (A), and then B is merged back in and deleted.
As stated, not all situations have been tested, so try some out and post the conditions in a comment below!
This definitely needs more than a few pairs of eyes to review since so much has changed.
Let me know what you think. 🎉
Images:
Simple sample
+-------------------------+-----------+-----------+-----------+-----------+
| Num. Commits | 301 | 301 | 301 | 301 |
+-------------------------+-----------+-----------+-----------+-----------+
| Time to load only | 7.758ms | 8.871ms | 8.041ms | 6.143ms |
+-------------------------+-----------+-----------+-----------+-----------+
| Time to load and render | 496.462ms | 446.530ms | 484.833ms | 525.960ms |
+-------------------------+-----------+-----------+-----------+-----------+
Chaotic Branching Sample
+-------------------------+-----------+-----------+-----------+-----------+
| Num. Commits | 8 | 8 | 8 | 8 |
+-------------------------+-----------+-----------+-----------+-----------+
| Time to load only | 0.611ms | 1.058ms | 1.232ms | 0.653ms |
+-------------------------+-----------+-----------+-----------+-----------+
| Time to load and render | 26.121ms | 49.863ms | 108.290ms | 26.132ms |
+-------------------------+-----------+-----------+-----------+-----------+
Many Branches Sample
+-------------------------+-----------+-----------+------------+-----------+
| Num. Commits | 301 | 301 | 301 | 301 |
+-------------------------+-----------+-----------+------------+-----------+
| Time to load only | 7.781ms | 6.254ms | 4.360ms | 14.538ms |
+-------------------------+-----------+-----------+------------+-----------+
| Time to load and render | 774.358ms | 447.554ms | 1369.974ms | 550.212ms |
+-------------------------+-----------+-----------+------------+-----------+
The average time it takes to conduct branch collapsing is
The branch collapsing has been optimised with an "available channels" cache, so we're no longer looping through every branch, every time we need collapse branches. Instead, we only do it the first time.19.175ms (averaged over 69 branches). This will be optimised before this PR is finalised. Why does it take ~20ms? Because we're checking every branch if it can collapse by looking at the surrounding commits to determine if the block channels.
I got a request asking for a bundled version because they were unsure of how to do it themselves. I've bundled and released it on GitHub, so for those looking to do the same (to either test or use, idm), it can be found here:
- VSIX File: https://github.com/TheBrenny/vscode-git-graph/releases/tag/vsix-creation
- Instructions: https://code.visualstudio.com/docs/editor/extension-marketplace#_install-from-a-vsix
Good to see you've made progress on this! Would you mind posting a screenshot of what's currently available so far for this feature?
I see you have some close-ups of some branching edge cases. It would be cool to see what the overall UX is like, since I might want to switch to this in the mean time if it looks transformative enough.
Tested it a little bit, two my persistent branches behaves correctly, but everything else is just broken. I had high hopes, but it still need more work to be usable.
-
https://prnt.sc/-y-KrvY9W0x5 This part looks fine (yet), it will be our starting point. There is a lot of overlapping below.
-
https://prnt.sc/sLSt9FXM3Kpi After merging branches (pink to orange), orange branch was pushed to third column and now it's overlapping everything else.
-
https://prnt.sc/U6kIvqHIofxc After merging green to pink, everything below (entire tree) got pushed to 4+ column, orange branch is overlapping one of green branches.
-
https://prnt.sc/QtxQHhbE4jWA After merging green to pink then pink to blue, overlapping stopped compared to point 3, columns 4-6 switched places, everything below red branch (entire tree) got pushed to 5+ column.
@Keavon
Would you mind posting a screenshot of what's currently available so far for this feature?
The idea of the close-ups is to provide some level of understanding of what it will look like when given those certain edge cases. There is zero change to the UI (except for this priority algorithm, and one setting), so you should expect it to look and almost certainly behave in the exact same way as the base GitGraph implementation. Do you have something in mind that might be different? I'm happy to hear feedback!
@ccarderr I see the strange behaviour between screenshots 1 and 2 🤔. Do you have this repo available for me to test with? Also, are your descriptions correct? "Merging Pink to Orange" sounds like Orange is the base (but not prioritised) and Pink is the foreign, which is proritised? This might help me in tracking down where the algorithm falls short. Particularly because the merge commit doesn't look like it belongs to a branch, except for the original Orange commit. Indeed, screenshots 3 and 4 look broken. Like I said, if you have the opportunity to send through the repo, or if you can give me more context behind the branches themselves (their names and the priorities given, and if they're deleted or not), then I can get started on investigating.
Either way, thank you both for the feedback! This is exactly what I'm looking for!
The idea of the close-ups is to provide some level of understanding of what it will look like when given those certain edge cases. There is zero change to the UI (except for this priority algorithm, and one setting), so you should expect it to look and almost certainly behave in the exact same way as the base GitGraph implementation. Do you have something in mind that might be different? I'm happy to hear feedback!
@TheBrenny Understood, thanks for clarifying. I thought this may have implemented some of the proposed ideas in the issue about designating "pinned" columns for specific branches and wanted to see what that looked like if that was the case. Good luck getting this landed!
Understood, thanks for clarifying. I thought this may have implemented some of the proposed ideas in the issue about designating "pinned" columns for specific branches and wanted to see what that looked like if that was the case. Good luck getting this landed!
If I understand correctly, you're asking if you can easily assign branches a priority from the graph itself? I'll take this on board and add it to the todo list, because this sounds like a good idea!
@ccarderr I see the strange behaviour between screenshots 1 and 2 🤔. Do you have this repo available for me to test with? Also, are your descriptions correct? "Merging Pink to Orange" sounds like Orange is the base (but not prioritised) and Pink is the foreign, which is proritised? This might help me in tracking down where the algorithm falls short. Particularly because the merge commit doesn't look like it belongs to a branch, except for the original Orange commit. Indeed, screenshots 3 and 4 look broken. Like I said, if you have the opportunity to send through the repo, or if you can give me more context behind the branches themselves (their names and the priorities given, and if they're deleted or not), then I can get started on investigating.
No problem, I will clone the repo and give you access. Description on point 2 is correct, I'm merging pink to orange in order to apply new changes that was made since last time I worked on the orange branch.
Simple description: Two first columns are prioritized. First column is LIVE, its equivalent to master since it has everything that goes to user. Second column is DEV, it's to accumulate changes and test if everything works before merging to LIVE. The rest are various changes or new functionalities I work on, and I don't merge them back to DEV until ready for publication.
It may be a little bit messed up compared to other repos, but it's not like I'm professional programmer anyway. :)
@TheBrenny did you mean to close this issue on mhutchie's repo even though you're merging that feature into your personal fork?
There was no intention to close this PR, but I guess that was a side effect of merging into my personal repo and deleting the branch lol.
I've accepted the fate of this repo, so I'm maintaining a version before I build something new from scratch over the holidays.