Improve Commit Details View File Tree for deeply nested directory structures.

[niccolomineo]

In git-graph's commit tree, if you have a file located in a directory that's a leaf of a deep enough tree, the icons next to the filename get cut beyond the right cell margin.

Steps to Reproduce
Steps to reproduce the behaviour:

1. Go to the git graph
2. Click on a commit in which a file is in a directory that's a leaf of a deep enough tree
3. Icons next to the filename get cut beyond the right cell margin.

Expected Behaviour
I should be able to see and click on each of those icons. Having a horizontal scrollbar for that table cell could help.

Environment

• Git Graph Extension Version: 1.24.0
• Visual Studio Code Version: 1.46.1
• Operating System: MacOs Catalina

[mhutchie]

Hi @niccolomineo,

The current behaviour is by design, and is consistent with the Visual Studio Code Explorer View (which also doesn't have horizontal scrollbar, and just truncates the content horizontally). This pattern is relatively common for many file-tree-like views across different software products. Without a horizontal scroll bar it's difficult to intelligently abbreviate file-tree-like content, as everything is important (e.g. the folder structure, file name, additions / deletions, action buttons). There is no universal solution of what should be hidden first, so many products simply truncate the content (as does Git Graph). For example (assuming the current behaviour without a horizontal scroll bar), if I were to change it so that the buttons always appeared on the right and didn't overflow, this would mean that the filename / additions / deletions would have to be truncated if the content overflows - in which case the buttons are meaningless if you don't know what file they're for.

Currently in Git Graph there are two ways that help to minimise / eliminate horizontal truncation in the File View side of the Commit Details View:

• The divider between the Summary Information (LHS) & File View (RHS) can be dragged horizontally, so that more horizontal screen real-estate can be dedicated to the File View.
• The File Tree View option reduces horizontal screen usage, while increasing the vertical screen usage when compared to the File List View option.

Additionally, when I first implemented the Commit Details View and decided to truncate horizontal content if it overflows, I kept monitoring for any users reporting that they worked in repositories that are deeply nested, where the current truncation may be less than ideal. In the ~14 months since, and over 500,000 users, not a single other user has raised it as an issue to me (you're the first). Up until now, that was a very good indication to me that the current, very simple, horizontal truncation approach was sufficient for the majority of users, and it wasn't worth adding significant complexity to the code for something that wasn't deemed necessary by users.

If it's possible, it would be great if you could reply with a screenshot of an affected Commit Details File View, as it would give me a sense of the structure of the repository and how you work. I don't care about the file names themselves (you can blur or paint them out if they're confidential), I'm just interested in the structure. Visual Studio Code recently introduced a folder grouping mechanism that reduces the horizontal and vertical consumption of file trees by inlining nested directories with only one child directory - perhaps this is something I could do to help reduce the horizontal usage of the Commit Details File View (in File Tree Mode).

I'm definitely keen to improve the Commit Details File View for deeply nested repositories, I just think it's best to try to find a solution that reduces the horizontal content if possible, so that as much of the content is visible without having to truncate horizontal content or scroll at all.

[niccolomineo]

Hi,
I did try to shrink all the other cells in the same row, but it still wasn't enough. I cannot find the repo I was dealing with that made the problem occur at the time and indeed the people affected would be just a fraction of all the users: it's one of those edge cases that, whenever they show up, they make the user feel as if the software is broken, but not every users will ever get to the point of facing such issues (or maybe they will, but not regularly). If you ever believe this should be addressed, my suggestion is not to go as far as sacrificing the filename nor the icons: the scrollbar would be just the right solution.

For the sake of completeness, I can scroll the explorer sidebar horizontally (not sure why you cannot):

Btw, keep up with the great work on this extension. I use it in my daily work and it really opened to magic actions the normal git + VSCode combination wouldn't allow me to perform. Thank you!

[mhutchie]

@niccolomineo, that's really interesting that you have a horizontal scrollbar on the Explorer sidebar, I just checked on a MacOs Catalina computer and I also don't get one on it either (my screenshot was on Windows).

In any case, the perspective I was trying to convey was that I think there are some interesting solutions that may be better for the user than sacrificing the filename/icons, or adding a horizontal scroll bar. I'll explore these possible solutions and reply back with my findings and implementation, as I definitely want to address this current limitation on deeply nested repositories asap.

I'd be keen if you're able to find a screenshot at some point of the repository you were facing this issue with.

[mhutchie]

I've enhanced the Commit Details View File Tree renderer to better display deeply nested directory structures, such that folders with a single child folder are compressed into a single combined folder element. This:

• Effectively eliminates the need for a horizontal scrollbar as the files are now indented far less, making a lot more room for all information of file nodes (filename, additions/deletions & action buttons).
• Reduces the vertical space usage of the file tree, as qualifying nested directories are now displayed on a single line.

This will be available in v1.25.0, which will be released in the next day or so.

I'll get more feedback on these changes from a variety of users after the release, to see if the implemented solution meets the needs of deeply nested directory structures. I'm more than happy to make further changes should it be necessary. Please let me know how you find the enhanced renderer after the release, once you find the affected repository you work on.

[niccolomineo]

Hi, hope all is well. Is there a release date slated for 1.25.0?

[mhutchie]

Hi @niccolomineo,

I’ve been very unwell the last few weeks. I’d initially planned to release Git Graph 1.25.0 two weeks ago after implementing this feature, however I wasn’t well enough to do my final testing for the release.

This weekend I felt slightly better, so I managed to complete my final testing of Git Graph 1.25.0. I intend to release it tomorrow.

Apologies for the delay in getting this functionality released.