phil294
Problem with rendering of repository with many branches
If you have a repository with many branches, it reserves space for all branches which is not very optimal. See here:
The top:
Scrolled a bit down where the maximum of branches are:
The default -n is -n 15000, and iirc, you could configure the number on the UI. -n 30 was enough to my cases.
One of the core designs of this extension is the usage of vue-virtual-scroller which allows to scroll beyond thousands of commits without major stuttering (hopefully). The only way to meaningfully solve / get rid of the large blank space in your first screenshot I can think of would be to not load many commits at once and instead keep loading more and more the further you scroll down, just like Git Graph does. But I'm not sure this is a good idea. I actually like how you can scroll over large time frames (often until the very end) in one go. Regardless of this, it might be worth considering adding a "load more" logic at the bottom either way - there may be more commits after 15,000 and it would be more convenient to click on that instead of having to replace 15,000 with 100,000 or whatever.
It's also true that you could just reduce 15,000 to, say, 30 or 500, but this doesn't really solve the issue at hand...
With that said, I can see a few other problems here:
every branch still takes two pixels. The auto branch column width detection chooses between 2 and 10, but it should actually be 1 and 10. You could also set the option
"git-log--graph.branch-width": "1"in the meantime. It will be uglier but take up less space.the commit info row should probably have a higher visibility than the graph branches
- with hundreds of branches next to each other, this whole rendering arguably becomes next to useless anyway. I think there should be a checkbox somewhere to just disable the branch visualization altogether on a per-repo basis.
this is also pretty useless but I don't have a better idea how to show it. Note that you can hide this entire area with a config setting too
the author name should not take up half the space, as the message is usually the most important information of the entire row
I'll be glad to optimize everything toward a better experience for very big repositories, I'm just not very certain on how to solve these issues
The default
-nis-n 15000, and iirc, you could configure the number on the UI.-n 30was enough to my cases.
This fixes the spacing of the branch lines, but it still reserves space for all branches.
The only way to meaningfully solve / get rid of the large blank space in your first screenshot I can think of would be to not load many commits at once and instead keep loading more and more the further you scroll down, just like Git Graph does.
No no no, please not. This is one of the biggest disadvantages of Git Graph compared to other tools IMHO.
Why not do it like Git Graph? Just put an overlay over the graph lines:
Setting "git-log--graph.branch-width": "1" makes it worse - then the workaround to limit the displayed commits doesn't work.
the author name should not take up half the space, as the message is usually the most important information of the entire row
And I personally think the commit message is more important than the commit hash so I would show the commit message next to the branch lines. But I guess this could be done with the settings and I must admit that I just looked into this some hours ago today. Furthermore I don't know if there are "real columns" or if it is more the output of git log.
Another thing - did anyone notice these zig-zags here? Its weird that they are even clickable:
[
-n 30] fixes the spacing of the branch lines, but it still reserves space for all branches.
this is apparently a bug, as the width doesn't seem to update properly. If you set it to -n 50, then SAVE and then restart the view/tab, you'll see that it updates the width properly (unless I misunderstood you)
No no no, please not. This is one of the biggest disadvantages of Git Graph compared to other tools IMHO. Why not do it like Git Graph? Just put an overlay over the graph lines:
the problem is that the visualization at the left isn't one single svg, it's actually individual rows each containing their own svg. That's why I haven't made this stuff resizable yet. But I guess it's not too complicated and should be implemented. Not only that, I'd like all columns to be resizable, moveable and hideable. Customization for ever!!!
Setting "git-log--graph.branch-width": "1" makes it worse - then the workaround to limit the displayed commits doesn't work.
I don't know what you mean by that unfortunately - this
looks dense but appears to solve width issues by 50%. But maybe it was just that bug above again where you needed to restart the view.
I don't know if there are "real columns" or if it is more the output of git log.
Everything (graph chars, commit message, author etc) but the red/green progress bars stats (deletions/insertions) is taken from a single git log --graph --format=... invocation, then parsed into commit objects and displayed properly. The stats are loaded on demand. So anything is possible.
Another thing - did anyone notice these zig-zags here?
All lines, including zig-zags, are always exactly what said git log command returns, just in a more colorful manner. Lines without a commit are rendered thinner, however: 6px instead of 20px. I did this so they take away less vertical space. If they were just as big as the normal ones, it would look like this:
prettier but bulkier.
The thinner solution also has the downside that these lines don't look particularly great:
I'm afraid it's something that cannot be easily solved though.
But still, your screenshot begs the question, why does it show
for you but
for me? Would you mind sharing your
git --version?
Anyway,
Its weird that they are even clickable:
yeah they really shouldn't
btw I just realized the branch section can already be hidden entirely by changing removing the --graph from the log command
haha yes I could reproduce the zig-zagging by running the git log command in an older Debian Buster Docker container:
so you can get rid of this very particular zigzag by upgrading git / your system. Fascinating :-)
[-n 30] fixes the spacing of the branch lines, but it still reserves space for all branches.
this is apparently a bug, as the width doesn't seem to update properly. If you set it to -n 50, then SAVE and then restart the view/tab, you'll see that it updates the width properly (unless I misunderstood you)
This is what I meant that the space for the branch lines is still reserved:
looks dense but appears to solve width issues by 50%. But maybe it was just that bug above again where you needed to restart the view.
Ah ok I need to close and open the view. I thought that was done with the reload button.
Knowing that, gives a nice view when only looking at a small number of commits:
But still, your screenshot begs the question, why does it show image for you but image for me? Would you mind sharing your git --version?
You cloned linuxcnc just for testing? Awesone :star_struck:
Very interesting the observation that git log --graph --oneline does have those zig zags. I am running git 2.17.1 on my old Ubuntu machine and even a Debian Bookworm with git 2.39.1 shows those artefacts. Really weird !!
Ah okay then it seems the relevant --graph change was introduced in git 2.40.
I have fixed some of this stuff locally but I'm on vacation for a few days so you'll have to wait for more releases for 1-2 weeks now I'm afraid.
Yeah interesting with git 2.40.1 it doesn't show those zig zacks.
But there are still some elements that are important to show but shouldn't be clickable:
But this is complaining at a high level :upside_down_face:
Just noticed that even Git 2.41 on Windows have those zig-zacks. But just for information - there are way more important things to improve =).
In this case it's actually as expected, the latest git version graph always looks like that in some spots. The version discrepancy was only present for that very specific other situation
Is it better/possible to change the way it renders the graph?
In the following screenshot, the left one is generated by cweijan.git-graph-history3 (unfortunately, it's no longer available on GitHub or the marketplace). IMO the left one is more readable than the right one. BTW, the emojis seem to be rendered in the wrong way.
@Alecton4 possible, yes, but unsure how complicated. Currently this is just the way it is returned from Git itself.
I have now revised the branch rendering, and also made the branch area resizable. It's a bit hidden because there is no column header but after just a few moments of using the extension you will have noticed the resize cursor between branch lines and commit message, that's why I simply went with not wasting any more space by adding a header for now.
Also the default branch line width is (while still being configurable) now no longer dependent on the total amount of branches painted in parallel because of this - the default is now simply always 10 (px per line)
So I think everything written in here is pretty much fixed now. If you still have suggestions on how to improve the experience for repos with a ton of branches feel free to leave it here, otherwise I'll close this some day.
Yeah that's really cool, thanks for that! But how can the minimum width be reduced?
In this example the width can only be increased:
@hansu oh yes there's still a min-width and a max-width in place so you don't accidentally completely hide the area. It should just be a few pixels though, not the 15-ish vw (?) it currently is. Will change this soon
Just noticed a little thing: The branch name is always on top.
I think It should be hidden, if the correspoding "bubble" is not visible any more: