1

Pull Request File Tree Feedback

 2 years ago
source link: https://github.com/github/feedback/discussions/12341
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

🆕 Pull Request File Tree Feedback #12341

🆕 Pull Request File Tree Feedback #12341
9 days ago · 154 answers · 97 replies

For the past few months, we've been working hard to improve the Pull Request experience. One of the features we're most excited about: Pull Request File Tree. The new tree:

  • Improves ease of navigation between files
  • Gives you a quick understanding of the number and types of changes
  • Helps you focus your review by letting you filter the tree by file or folder name

How to enable the preview

The feature preview is rolling out now. Once it is available to you, it will appear in Feature Previews. Just enable the Pull Request File Tree feature.

Known issues

We're still working on the feature. Here are a few known issues that you may encounter:

  1. The state of the "Show/Hide file tree" toggle is not remembered (the plan is to store in local browser storage)
  2. There are a few quirks related to the scroll position when a file is clicked in certain cases (like when clicking the same file twice in succession)

Feedback

Your feedback will help inform what's ultimately shipped in the public release, so please let us know what you think below. We're excited to hear from you sparkles:octocat:

Replies

154 suggested answers
97 replies

Great addition to PR reviews! This is a much easier way to navigate and visualize changes in a PR. If/when this hits public release please give the option to pin it to the right side instead of only the left!

1 reply

Thanks for the feedback! We'll look into it.

Looks good! Even if really big PRs, I can finally filter using part of the filename, which was close to impossible before! 👏🏼

0 replies

Great addition! But I think, that a indicator should be added, at which File you are currently looking (because you can scroll like before, but the indicator itself does not update its location)

7 replies

If you click the file name on the left it should highlight the file view for the file you are looking at in a blue outline?

Maybe highlight background of the tree showing which files are currently in view? A bit like sidebar in some code editors (eg. this from Atom minimap addon):

Maybe highlight background of the tree showing which files are currently in view? A bit like sidebar in some code editors (eg. this from Atom minimap addon):

I think, that this would be a great addition too

Looks great so far tada if I had some suggestions for improvements:

  • Hiding/marking files after being marked as "viewed"
  • Resizing of the left size panel, for those longer files and folders

And a single bug I've come across

  • The top file or folder is hidden when stickied to the top after scrolling if you have a notification banner visible
12 replies

+1 on option for hiding reviewed files from the file tree, sometimes we have PRs with 300+ files and it becomes a hassle to navigate such a file tree in this case. Having the option to hide reviewed/viewed files would help tremendously.

+1 I think it would be great if viewed files and folder containing only viewed files had a green tick or something like that indicating that they have been marked as "viewed".

Also, a good default could be that folders containing only viewed files are collapsed by default

@tngranados Yea, a green mark or any kind of indicator would be enough :)

Great addition! ear_of_rice

Found a possible bug:

  • The first file/folder in the file tree is scrolled under the notification bar when scrolling.
3 replies

Same here, will tag on with my detail. Looks like when selecting the first directory/file in the tree ([class^=file-tree-item]), the window scrolls down to match the top of the "Conversation", "Commits", etc tabs (.tabnav). When clicking either any file in the tree other than the first, it scrolls down past the first previewed file (.file), which then uses the floating pr toolbar (.pr-toolbar). Seems like this might be because the floating header only shows once your viewport meets the top of the first previewed file. Not sure if that scrollto logic needs to have the offset updated to make sure it scrolls enough to show the floating toolbar without hiding the file title (.file-info). Sorry for the lack of screenshot/video, can't share from this repo.

I'm seeing this as well. Here's a couple of screenshots if that helps:

folder hidden under top bar

Then if I scroll the main page all the way up, only then does it show:

folder shown at top of main page

I'm seeing this too. If I dismiss the notification banner, it works as expected, but I think it should also show the first files even if I haven't dismissed the notification.

Looks good. As a suggestion I would like to see which files have comments in the tree.

2 replies

+1 I'm also missing this after using Better Pull Request for GitHub Chrome plugin for years already

I had to disable this preview and keep using that plugin.

Looks not so good on 4k resolution:

3 replies

Transforming this into constructive feedback: It would be great if long file names and deeply nested files would be shown completely, especially where large screens offer a lot of space. Maybe make it a resizable pane?

I agree, if they keep the 100% width, then there's room to enhance the tree max width based on resolution. The main issue I see is actually the code diff, it is hard to read (and compare) texts spread across the entire screen. Even the side-by-side code diff still has a lot of empty spaces.

Another suggestion would be to let the user choose the screen layout, between full-width or limited to a shorter range. If I remember gitlab has an option like this that affects the entire app.

Code diff of 100% is way too big on higher resolution screens (especially if the project is using a col limit of 80) and doesn't change to the old width if hiding the tree either.
I had to enable the feature preview and disable it again to get back to a sane width of the diff.

Please provide an option so the diff is limited in size + centered like without this new feature.
In the current state it makes reading through a diff way too difficult.

I like it but I wanted to disable it to test something but disabling it in feature preview does nothing and I still seeing file tree.

6 replies

You can hide tree via small text link that appears above tree

I think I had the same problem.

Just do a reload with F5 or Ctrl+R or even Ctrl+F5 or Ctrl+Shift+R.

The enabled disabled status seems a bit unstable.

Thanks for the feedback. There was an issue on Friday where the tree was enabled for everyone, but nobody could disable it as a feature preview. This has been addressed. We're also working to save the state of the hide/show toggle, so you don't have to continually toggle it off to hide.

Love the new feature.
I have a potential feature suggestion.
Could a shade of colour be added to the tree for all of the files that are marked as viewed?
So for argument's sake, if we mark a file as viewed, a light grey color gets set in the file tree.

Here is a mock up of how it could look if a file is marked as viewed

2 replies

Maybe just dim viewed files, and also a button to hide them completely (also hiding any folders that are fully viewed)?

Agree! It would be very useful!

This is a great feature!

I am already using an extension for PR tree, is in the road map to implement the features of the browser extension?

  • diff stats next to file
  • count of the changed lines
  • icons
  • indication that there are comments on the file
4 replies

In addition, it would be great to show "checked" icon near file if files a "Viewed" (checkbox)

Aren't we soon gonna have a vscode instance built-in with this many features? smile

Don't get me wrong, the seem cool but just a little (to) much.

Really love that extension, all the indicators it adds really contribute to the efficiency of reviews, which I do a lot of.

Nice addition. The feature does not seem to work in the commits tab of the PR. In our shop, we typically do commit-by-commit reviews and rarely use the files changed. It would be nice to have the file tree in commits as well.

2 replies

Second that! Commits tab and commits comparison as well! +1

+1 Please add support for commit-by-commit reviews. I love how @berzniz handles it in his chrome extension.

This is such a great feature.

0 replies

First of all amazing feature, cheers!

In a long diff, clicking a file name for the first time correctly positions the view and highlights the file with blue marker but clicking a second time moves the view a bit down and obscures the highlight.

I would expect the second click do nothing -- maybe fold/unfold the file.

1 reply

Thanks for the feedback. We're looking into this.

It's really useful but some minor points:

  • It's eating lots of horizontal room, making side-by-side diffs a bit harder to read
  • Maybe shrink the font size a bit?
  • Maybe have a splitter that allows tree width to be reduced/increased?
  • Tooltips on the glyphs at right hand side of tree (eg. denoting new file, changed file, etc) would help new users
  • Maybe dim the folders + their names (unless they are added/removed) to make changed file names stand out more?
  • Would changing colour/hue/whatever of / slashes in folder paths help differentiate from the folder names?
  • Maybe file type icons, except for the most common filetype in a repo? (eg. in csharp repo, things like csproj and sln would get custom icons to make them stand out, but cs files would use default icon to reduce visual complexity)
  • An option to view only file selected in the tree (eg. hide everything else so I can focus on that file)
  • Some way to see in the tree whether file is marked viewed?
1 reply

An option to view only file selected in the tree (eg. hide everything else so I can focus on that file)

I'd be happy with just having the search show/hide the file in the main view, rather than just in the tree side-panel. Because some projects commit their library files into the repo (for reliability), some of the PRs I need to review have 1000+ files. If I could do something like hide all files under vendor/ (Golang) or under Node_modules/ (Angular) that would be amazing! :)

I like the ability to navigate the file tree, but I wish it would remember whether the drawer/sidebar was open/closed. I often have GitHub in a narrow window (as GitHub is fits comfortably in a narrow window), but with the file tree defaulting to open the space for the diff is greatly reduced.

2 replies

I came here to say exactly this! There are some PRs and repositories that I want it on, and some that I usually don't. It would be great if the tree would stay hidden if I've hidden it before - even as a global setting - instead of requiring me to hide it every time.

Thanks for the feedback. We're working on saving the state of the hide/show toggle.

It's almost perfect. Could it also display files not changed by the PR? Very often I want to see other filets get context information.

0 replies

I really like this!!

0 replies

really apreciated feature. One thing i would love to see : a small badge on collapse directories to display how many changed files are in

0 replies

Great feature. I would like to have directories and files sorted the same way as in the source view. So directories on top, files at the bottom, ordered alphabetically. It is something I am missing in the current diff view too.

I'm working with Bitbucket Server mainly for work, where this is the default. With large PR's, GitHub is a little confusing in my opinion mixing up directories and files.

0 replies

I tried the feature, but I have to say that I don't need this. Most of my PRs are small with low number of changed files. In such PR, the feature doesn't bring any value to me, only take space on the screen which is a reason why I disabled it.

On big PR, it would be helpful, but a button Show tree would be enough to display the tree if I need it. The default - tree hidden works better for me.

0 replies

This is a really great feature, and maybe it could also be integrated in the compare view. I believe it's the same principle as we just show 2 versions of some files.

0 replies

It'd be nice if Viewed can be marked in the tree

It'd be nice if the collapse on the left, also collapse on the right (which does not relate to the Viewed flag)

0 replies

I think it would make sense to add a toggle to show files which are unchanged by the PR especially if you are adding files or renaming/moving files

It is valuable to see you are adding files to the correct folders which is hard to determine given we can't see any of the other files or folders

0 replies

Using the screenshot in the original discussion post, I'd like to share a shortcoming of the current implementation of this feature. Here, 4 files were modified. The file tree shows these 4 files, but also 5 folders, since every file is in a different folder.

This isn't too bad for small PRs, but on big PRs that might touch, say 100 files, we're talking about potentially showing 100+ folders too, which adds a lot of noise to the view if the developer doesn't care about folder structure (or the folder structure is very complex).

I'd love an index like this on large PRs to help me navigate without needing to Cmd+F or scroll too much. Code-mods are examples of large PRs where this would be useful to me, but they are also example of PRs where this tree gets very noisy, since they often touch a bunch of different files in a bunch of different folders. I don't really care much about the folder these files are in when I'm code-modding.

A toggleable and persistent "List View" option would be very helpful here. It would show all files and be filterable just like this tree view, but display them in a flat list, and so skip on also displaying all the folders, indenting the entries, etc.

0 replies

icons (+ -) in the file makes it looks like expandable but indicating diff status. I think it is better if we can adopt green/red squares similar to other places in github.

0 replies

Huge fan of this! I would love if folders were grouped and sorted alphabetically followed by files grouped and sorted alphabetically though, instead of just alphabetizing everything both together

0 replies

The ability to approve individual commits would be great.

0 replies

Feedback
OK if you want to get an overall feel for the files being changed (2% usage for me).
However, it is not practical to do Code Reviews with it open (98% usage for me).
The current "Files changed" tab design already makes reviewing code with 80+ char lines difficult to read (b/c of line continuation)
Opening the File Tree makes the problem worse.

Suggestion
Would be nice to be able to collapse all folders or all folders of one level.

Question
I see folks with orange and green squares.
How does it turn green?

1 reply

Yellow means file edited, green means new file, red means file deleted

Love what I am seeing.

Would also like a way to bulk 'view' - so don't have to click through hundreds of 'view' [ ]

0 replies

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK