Skip to content
This is a ✨special✨ repository containing the organization level discussions for github-community. Everything posted here will also be visible at the organization level.

🆕 Pull Request File Tree (Beta) Feedback #12341

Unanswered
willsmythe asked this question in Pull Requests
🆕 Pull Request File Tree (Beta) Feedback #12341
Mar 3, 2022 · 2,360 answers · 614 replies

willsmythe
Mar 3, 2022
Collaborator

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:

  • Jump between files more quickly
  • Understand the size and scope of the change before you start reviewing
  • Focus your review by filtering the tree on part of a file or folder name

See the changelog for [a few more] details.

What you need to know

  1. The file tree only appears if the pull request has at least 2 changed file and your browser window is sufficiently wide.

  2. During the beta, you can disable the tree completely via the feature preview dialog. When disabled, you will no longer have the option to hide or show the tree from the pull request page. If you change your mind, you can re-enable the tree in the feature preview dialog.

Most common issues

The full list of issues we're tracking is longer than this, but the following are the most commonly reported:

  1. Ordering of files and folders under the same parent (including the root) is not always correct
  2. Accessibility-related issues (e.g. cannot navigate the tree using the keyboard)
  3. Tooltip missing on truncated file and folder names
  4. Tree does not resize properly in some cases
  5. T keyboard shortcut not working

Feedback

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

Replies

2360 suggested answers
·
614 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!

46 replies
@willsmythe

willsmythe Mar 3, 2022
Collaborator Author

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

@na1489

also would be nice to be able to increase or decrease the size of the bar itself, like holding it on the edge and dragging it to the right to increase or left to decrease amount of space it takes up on the page itself

@Logicbloke

Keeping it on the left side (like it's common to have the files tree on all editors) and adding the ability to collapse it, is all I need to be honest. Adding drag and drop functionalities to GitHub will probably require loading extra JS libraries and introducing new elements of interacting with the site that people are not expecting to see. Just my 2 cents.

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

17 replies
@efd6

It would be nice if using the nav pane to go to a file also unfolded the file if it is currently folded.

@needpower

Before this feature, i used Ctrl+F, i.e. native browser search, to find a file in PR. Now searching is much more convenient. Thank you guys!

@sdvauld

Dance Madi

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)

21 replies
@gwillcox-r7

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?

@aubergine10

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):

image

@TheFruxz

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):

image

I think, that this would be a great addition too

Looks great so far 🎉 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
63 replies
@gwillcox-r7

+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.

@tngranados

+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

@matteokov

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

Great addition! 🌾

Found a possible bug:

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

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.

@heaths

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

folder hidden under top bar
Screenshot 2022-03-03 100538

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

folder shown at top of main page
Screenshot 2022-03-03 100445

@agusmba

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.

13 replies
@TimWerdin

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

@StingyJack

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

@asos-edgeorge

For me, this is the one feature that is missing that makes GH's implementation something that I would disable. The rest of it is ace, but not knowing where the comments are at a glance is a huge disadvantage

Looks not so good on 4k resolution:

image

23 replies
@johannesvollmer

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?

@rafaelrenanpacheco

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.

@Consolatis

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.

14 replies
@aubergine10

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

@DanielRamp

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.

@willsmythe

willsmythe Mar 7, 2022
Collaborator Author

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

Screenshot 2022-03-03 165139

7 replies
@aubergine10

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

@kowolm

Agree! It would be very useful!

@jiaranda

Great idea!

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

Screenshot_2022-03-03_14-59-02

16 replies
@oleg-andreyev

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

@DanielRamp

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

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

@Klaster1

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.

5 replies
@iomariani

Second that! Commits tab and commits comparison as well! 👍

@EzraLopez

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

@tsdorsey

I'm seeing it in the commit by commit review but only when the commit contains more than 1 file.

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.

3 replies
@willsmythe

willsmythe Mar 7, 2022
Collaborator Author

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

@GoudekettingRM

Amazing feature indeed! I see that clicking a second time makes the page do a weird jumpy (to top of page and back) thing on my system. It keeps the highlight and stays positioned correctly though.

@meysam101

okoko

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?
16 replies
@etarasoff-va

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! :)

@vikramaditya234

Would be good in case I can hide the tree altogather

@lrhn

I needed to expand the browser window significantly to make room for everything, and after doing that, the split was no longer in the middle of my view. I did not know how important that actually is (to me, at least). It made visually grokking the diff quite a lot harder — until I moved the window so the split was centered, and the file list was partly outside the screen.

At least make it possible to shrink/minimize/scroll out the file list, so the browser viewport centers on the split between the files in the diff.

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.

7 replies
@nickvanw

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.

@willsmythe

willsmythe Mar 7, 2022
Collaborator Author

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

@vahe

@willsmythe I think support for narrow window and saving state should be separate features.

Currently when the diff is in "Split" view, the filetree hides only when width is under ~1000px. This makes it unreadable between 1000px - 1200px range. (I presume numbers may vary by browser or device 😄)
With Split diff view the filetree should probably hide when window width is around ~1200px.

Loved the feature, thank you..!!!

0 replies

I think it is almost ready for deployment, however it would be great if the icon to toggle show/hide would be accessible even after one scrolls the page down.

0 replies

This is great

0 replies

how about resizer line for file tree content size? long string is limited by your thin content box
it support on better pull request extension (https://chrome.google.com/webstore/detail/better-pull-request-for-g/nfhdjopbhlggibjlimhdbogflgmbiahc)

image

Screen.Recording.2022-05-10.at.3.57.35.PM.mov
0 replies

it is need to show checking icon for viewed file

it support on better pull request extension (https://chrome.google.com/webstore/detail/better-pull-request-for-g/nfhdjopbhlggibjlimhdbogflgmbiahc)

image

0 replies

Could you add a way to review PR "chunk-by-chunk" instead of "file-by-file", so instead of marking a file as "viewed" we could mark each "chunk" one by one. It would be a major improvement for reviews when files are big and have many changes.

0 replies

This feature looks really promising.

I think it could be a little bit helpful when the file that is currently at the top on the right side is being highlighted in the right side so that you can quickly find the file that you are currently watching.
I think it could be the same highlight as when you are clicking on the file in the tree.

I don't know if I have explained it well and when I haven't I am sorry. (Maybe I will make my comment better later)

0 replies

Some comments:

  • It is a bit confusing in the UI (particularly for new users) to have two "File Filter"s one in the left bar and one on the top. Could they be combined somehow? I found myself accidentally trying to use the left one to filter for extensions which doesn't work so well (e.g. because .go also catches .gohtml). I think I was lured into this behaviour because that filter box is more prominent.

  • Not super obvious what the UI state is when no files are found and how to get out of it: maybe a message to this effect and a reset button / link?

  • Not obvious (no feedback in UI) that searching has no effect until you type at least three characters.

  • Not obvious that you are not filtering changed files (as the prompt says), but the filtered subset of changed files according to the selection in the top bar. Could say "Filter displayed files" or "Filter filenames"?

0 replies

I really like the feature, use it daily.
One small suggestion I have is to "sort by type". As in, group folders and files. Currently, you have the following order:

  • package.json
  • src/
  • yarn.lock

And it'd be better to have, for example:

  • package.json
  • yarn.lock
  • src/
0 replies

Hi!
I'm facing a very annoying performance issue:
https://www.loom.com/share/3b6fc08a1ab04ec68e7d4cc817636fef
I cannot explore the files if there are too many of them.

0 replies

Really useful. 👍

It can be perfect with the ability to mark multiple files (or a directory) as viewed.

Classical use case: dependencies embedded in repository.

0 replies

This has been a really great improvement. Thank you github 👍🏻

One suggestion, I've noticed when I'm viewing a PR that has enough files to make the file tree scroll and enough files to make the file content scroll that the scroll viewport of the file tree is cut off (when at the top of the screen).

image

(There are more files below the "chipidea" folder.)

If I scroll down so the PR UI collapses "up", the full scroll viewport of the file tree is visible

image

In the second image, I can scroll the whole file tree. This is a bit annoying when I come into a PR and am looking for a file in the file tree to jump to. It would be a bit faster if I could scroll through the whole file tree and find what I need and could jump to the file content instead of having to scroll in the content area first, then scroll in the file tree to find my file. Thanks for considering! 😊

PR referenced: https://github.com/torvalds/linux/pull/115/files
(no I don't work on linux, just found a PR with enough files to demo 😁)

0 replies

Found a minor issue, not 100% sure it is related to the File Tree, but it did not occur prior to its addition.

  • When scrolling to the bottom of the page, you get this weird glitching effect:
    UI Issue when scrolling down
    It does not show super well in the gif, but that top section that disappears just keeps appearing and disappearing really quickly, giving a flashing effect.

I'm using the latest Chrome version(Version 101.0.4951.64 (Official Build) (64-bit)) on Ubuntu 22.04

1 reply
@SabianF

This may also be related to a similar issue I posted, too

Indication on source tree to mark viewed files

When reviewing PRs with a large number of file changes, it's hard to keep track of what files you've reviewed because the majority of the screen has been taken over by the files you are viewing.

If you want to know what files you've reviewed, you need to scroll through the page to see if the file has the "viewed" checkbox checked.

It would be great if the source tree on the left can have an "eye" icon to indicate the files you've reviewed.

0 replies

The file tree is horrible. It truncates the names of directories and the names of files. When there are a lot of files I end up with an internal scrollbar on the page and I have to use the page scroll bar and the internal scroll bar and even then I only get a partial list of files. Please bring back the simple list of full file paths. The file tree is a major step backwards in terms of usability. At the very least, please give me a setting so I can turn the horrible file tree off and revert to the simple list of files.

1 reply
@rafaelsalomon

Just noticed another issue. I used to be able to highlight and copy the file names. That's no longer possible either.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
📣 feedback wanted 🆕 ANNOUNCEMENT Pull Requests Beta