🆕 Pull Request File Tree (Beta) Feedback

[willsmythe]

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 ✨

[dpromanko]

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!

[maliahavlicek]

I like it over all as I can at least skip over pesky folders like migrations, I just wish I could make the project navigation panel wider or horizontal scroll in it, when you prefix all your file names the same way, you have no clue how to jump to a specific file.

[jgmuchiri]

@kbrock

There is one already

[dacgray]

Would be very helpful to be able to navigate between files with up and down arrow buttons.

Would make scanning through big PRs easier and faster.

[zjipsen]

Regarding the "hide" indicator @jgmuchiri screenshotted, if that could be included on the panel as you scroll down, so you can hide or show it while you're deep in reviewing the code without having to lose your place, that would be awesome.

[Danilomd]

thx

[zoispag]

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

[swapnilken42]

This new feature is awesome. I like It

[techwithanirudh]

Dance Madi

Let's Dance!!!

Great addition!
Very awesome feature to Github!

[itsbiswa]

This is a great addition serves a great deal for reviewing in an organised fashion.

[AraHaan]

Now if only it flagged security issues in files by marking them in red for when someone tries to introduce a new security issue in pr.

[AmareshMuddebihal]

i like it

[TheFruxz]

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)

[aareman]

The files listed on the right side are in a different order than in the tree list. So lining up the background highlight wouldn't work, unless you change the ordering to match

[mjmikulski]

Maybe a bold font for the file that you are currently seeing? Instead of that little vertical bar.

[MeniKadosh1]

totally needed, it is confusing to scroll on the right while the tree not reflecting the currently reviewed file.

[rohit-userfacet]

Agreed. Makes a lot of sense to somehow highlight (with enhanced font or foreground)

[james-smith-za]

+1 for this. +several in fact.

[stephenwf]

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

[j2em6h]

+1 to resizing the left panel.

The indentation is quite large, compared to the Explorer view in VS Code for example, I find the files hard to skim when everything isn't as compact. Being able to expand the panel would help.

[PaulAtST]

+1 on resining the panel and marking files as viewed. Those where the two suggestions I came here to make

[ReneBurggraaf]

Mark folders (all underlaying files) and files as viewed from the left column would be great.

[shthiago]

+1 to marking files as viewed (not that much into hiding). For PRs with multiple files would help a lot.

[adrian-skybaker]

It's frustrating trying to visually parse a file tree that is crammed into a fixed width, narrow width column, combined with excess padding and overly large fonts. Even when full-screening a PR on a 40" monitor, there's no dynamic break point to increase the width, it still sits on the left as a tiny vertical slice of truncated file titles, with a mountain of unused space to the right.

Being able to resize will mitigate this, but it will be clunky, and there'd be less pressure to resize if the space was used more efficiently, and if the width scaled more sensibly with the window size.

The file tree font and layout is bigger than the code itself, and bigger than the file trees on every other tool I have open (Fork, IntelliJ, VSCode, MacOS Finder).

[nubcake94]

Great addition! 🌾

Found a possible bug:

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

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

[Chemaclass]

Yes, this happened to me too.

[heaths]

Strangely, now I'm seeing the opposite: the per-file top-bar is getting hidden under the PR top-bar:

To explain the image a bit more, the top-bar that has the "Viewed" check box is partially hidden by the PR top-bar and will continue to scroll out of view. At least for this "summary" view of all files*, I would expect the top-bars to remain unobscured until the entire file has scrolled out of view.

* On that note, with the folder view, why load all files? For large PRs, the file folders help go to a specific view, but page load and performance still suffers.

[wgu-kimberly-fawbush]

I noticed some odd behavior when all of the files are collapsed. If you click a filename, the page will try to infinitely scroll until you change focus by clicking anywhere else on the screen.

[jjspace]

EDIT: Don't do this anymore, they added some weird JS that detects an "original top" and using this style adjustment creates excess padding

I came to report exactly this. The height of the sticky sidebar is getting updated correctly when there's a notification but it's top value is not respecting the extra height added by the notification.

Using something like Stylus you can add this CSS rule and it get's fixed perfectly.

.notification-shelf ~ .application-main .hx_Layout--sidebar {
  top: 128px;
}

[skunert]

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

[dkrahmer]

I wrote a Tampermonkey script to enhance the tree view with several features. I just added comment counts and published it today: https://greasyfork.org/en/scripts/442885-better-github-pull-requests

[hazz0003]

Please incorporate this. Microsoft Azure DevOps has a nice visualization for this. Having used that as well. It makes a really measurable difference in productivity, especially on teams or commits with more than just a handful of files.. Comments become much more discoverable and the are shown in-context.

Simple Example below.

[sgolemon]

This suggestion is worth a comment to say "me too!". Especially looking for a "has comments" and a "has unresponded to" comments kind of indicator. Love the feature so far <3.

[wenmengzhou]

it is better to show how many comment in the file and how many have been resolved as follows

[dusktreader]

Yes, it would be good to be able to differentiate between files with comments and files with unread comments. Also, it would be great to have a way to page through comments groups rapidly.

[rafaelrenanpacheco]

Looks not so good on 4k resolution:

[paschini]

On 4k+ resolutions, it would be great to be able to drag the tree container to make it bigger for accommodation of big file names

[mzient]

To all commenting about fixed width: browser window is resizable, so you can scale it down if 100% width is a problem. Achieving 100% width (which I wanted even though I work on a 27" QHD monitor) when there's a fixed (pixel!), on the other hand, is not possible without browser plugins & CSS hacking (which I did before 100% width was there).

[sgolemon]

As a user with an ultrawide monitor, I can't agree more with the suggestion to unlock the width. I built this bookmarklet to allow me to double the width of the column (which is okay as a fixed size for me), but something easily draggable with memory between reloads would obviously be much more valuable. Barring that, a config setting to say "my preferred fixed size is $x px" would be a big step in the right direction and probably much easy to code in.

[boatcoder]

@rafaelrenanpacheco This could be a case of user error. Why would you do code review that isn't side by side on a 4K screen? Would you read google search results like that? Last thing I would want is for them to artificially narrow the screen because of a comment like this.

[Alberth289346]

You want to have the full path in general, in my experience, but there is no room for it if you stick it next to the diff.
Instead, can it be small bar at the left (eg for overview), and when you move the mouse to the left over it, a popup that covers say up to 1/2 the screen width? That would give you the space for everything

[DmitryBarskov]

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.

[billy-coursera]

In other code review tools I have used, I have been able to toggle the view of the file tree on or off based on a hotkey, for example "f".

[meysam101]

@meysam101

[effs]

The current icon is a bit too small for purpose (and also only shows at the top for me, not when scrolling no, wait, it's there). Better discoverability would be nice - maybe just make it a touch bigger? A highlight wouldn't hurt either, it gets lost in all the other graphical box borders.

An additional config option to auto-collapse would be a nice pair to a keyboard shortcut to show/hide.

Overall a nice improvement!

[jarbot]

I do not have the ability to hide it. I don't find it useful for large commits. It's just noise.

[m4rin]

UX: Struggled to find the icon to show/hide file tree.
On a 1450 px browser window, can't see 76 cols side by side with the file tree on.
Suggestion: reformat the default file tree with so you can still do 76 cols side by side diff?

[jpbnetley]

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

[jiaranda]

Great idea!

[ofirnk]

Great idea! I think that a checkmark ✔️ with an eye 👁️ will be nice.
Something like this (which I'm not sure if is allowed to be embedded here)

[MorganServettaz]

I would love to be able to mark file as viewed directly in the tree as well.

[smariano88]

It looks like adding this style does the trick

li[data-file-user-viewed] {
    opacity: .5;
}

[gyula-kun-szabo-epam]

Marking the folders as viewed when all files in that subtree are viewed would help continuing reviews quicker.
Also the comment markers with open/all count could appear on the collapsed folders if any file under that subtree has comments.
And when the folder is open the aggregated info should be hidden and the files and subfolders should show the relevant data instead.

[rochacbruno]

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

[damemi]

+1 for diff stats

[mherrerarendon]

+1 for diff stats. I agree that it would be helpful to easily find which files contain major changes.

[ramhr]

Would also like for the search bar to be anchored like in the extension, so you won't have to scroll to the top of the file list to search it.

[mjmikulski]

+1 for indication that there are comments on the file.

[dennisklein]

• indication that there are comments on the file

In addition to comments I would love to have an indicator for check annotations as well (or whatever they are called, see the picture for an example).

[aunsbjerg]

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.

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

[israelias]

Yes! I jumped here to add this exact feedback. Love this feature, and was hoping there would be some way to quickly reference or copy the commit SHA in the tree. But since there can be any number of commits to a file, it seems this could be offered as a file tree feature in the commits tab. Or via some way to cross-reference them in filtered files-changed to changes-from-commit.

A sweet version of that sync might be to have some detail in the file-info tab header that links the file to its commit history within the current PR.

[matt-adler]

+1 for icons

[tfevan]

This is such a great feature.

[senhalil]

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.

[willsmythe]

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

[aubergine10]

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?

[psiservices-ben-voytko]

Really want to be able to change the width of the file tree, we have large filenames that are cutoff, and so there may be half a dozen files that have the same leading characters that are cutoff and I can't tell which is which without clicking. Having full file name in tooltips is also desirable when it's truncated.

[alex-kim-dev]

An option to view only file selected in the tree

I would like to have this feature as well 👍

[mdione-cloudian]

Maybe have a splitter that allows tree width to be reduced/increased?

👍 + an option to hide id completely. My use case is portrait oriented monitors, 1080x1920 (WxH).

[mdione-cloudian]

an option to hide id completely

the option is there, just a row higher than I expected it. maybe by the search entry?

[jreidthompson]

The option to change the font size in the tree would be useful

[markstory]

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.

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

[techguybiswa]

Same issue i felt

[asmshaon]

It's beneficial to review code quickly and perfectly

[rdrh555]

Agree with nickvanw, default tree to hidden, or allow me to default it to hidden via a global setting.

[amold96]

+1 to this.
File Tree is an awesome feature 🎉, but I don't need it all the time (sometimes I need more space to view the code changes in split view). Ability to hide/unhide it with a simple toggle button and keeping the last setting in memory would help a lot.

[andrewleith]

Commit messages generally provide some context on individual changes, but when you view a PR of many commits in the file tree that context is lost.

Permanently showing them in the file tree might be overwhelming. Instead, would it be possible to show the commit messages related to changes in some subtle way? Perhaps by hovering or clicking on something?

[nilcolor]

Hi there!
I'm not sure if this hasn't already been written, but I couldn't find it. "GoTo" popups appear under the file title field.
It looks like the popup z-index is not set, while the file header has a z-index of 2.

Was seen in the Google Chrome Version 103.0.5060.53 (Official Build) (arm64)

[matuhinal]

Здравствуйте Алексей.Очень нужен специалист с вашими навыками.Вы в каком городе?1 июл. 2022 г. 03:25 пользователь Alexey Blinov ***@***.***> написал: Hi there! I'm not sure if this hasn't already been written, but I couldn't find it. "GoTo" popups appear under the file title field. It looks like the popup z-index is not set, while the file header has a z-index of 2. Was seen in the Google Chrome Version 103.0.5060.53 (Official Build) (arm64) —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

[ShiningBeam]

HELP!!

[ShiningBeam]

Where is my reader and can I use face instead of a password .

[iwan-ua]

A file that I moved to a different folder is displayed as a new added file, and the old one is displayed as removed
Even if that is eventually fixed, I think it would be nice if there was a way to indicate that those are the same files and they should be compared in the PR

[noritada]

I really like the tree view because it is useful to easily see the overall structure of changes and to get a quick overview of what parts of the file tree have changed.

However, I am a little disappointed that this is a feature of the review screen only. I also do a quick check on the screen when creating a Pull Request to make sure there are no omissions in the differences.

[patricklangsonos]

Is this feature out of beta? I do not see it under "Feature Preview" as mentioned in the first message. The bottom of the page has this error:

This PR is 296 files, and it's not the largest one I need to review. I filed a bug at support.github.com and am waiting to hear back, but would love a workaround if one exists.

[abelbraaksma]

I can only confirm that I don't see this option under the Feature Preview list of features to enable/disable anymore either. Perhaps it went back to the drawing board after feedback, but it would be nice to hear from @willsmythe (or any other Git contributor) why it was removed and whether or not it will come back.

[patricklangsonos]

That issue above (Oops, something went wrong) was resolved the same day, but I'm still not clear on the status of this feature. Can we opt-out of we have problems, or is this feature "Done" and there's no opt-out?

[TerryHowe]

Is this feature gone for good?

[akashagarwal7]

Something that would be really handy is an ability to horizontally extend the left-side pane for reading large filenames at a glance.

[jbojcic1]

Something that would be really handy is an ability to horizontally extend the left-side pane for reading large filenames at a glance.

It's really annoying that this is not possible. The tree is unusable for bigger names atm

[JeongSooNa]

I need it! Thank you!

[Ahmed124323]

Does anyone help me? I need to open this email.

https://www.facebook.com/profile.php?id=100081167605901

[sn-dustin]

If the Files Changed content it too short, the PR Review form gets cutoff. It looks like the element <main class="d-flex flex-column flex-auto overflow-hidden"> is the culprit.

[fragkakis]

This is a great addition ❤️, it really makes reviewing PRs much easier, as it provides a high-level view of the changes.

The same high-level view would also benefit the compare UI as well, where two versions (ie tags) are compared, and where no pull request is in place. For example, in this compare link below is what I see in the Files changed tab as of this writing.

Comparing the two versions would be much easier if the tree was in place.

[f-g-p]

Hi,
being a heavy PR reviewer, I'll share my 2 cents, in hope of contributing to improving the product.

• the ability to change the horizontal width is a must - especially for users who switch from laptop to desktop monitor all the time
• highlighting the currently displayed file in the three is also a must
• display viewed/un-viewed status on the tree. The "File filter" option to hide viewed files is not really handy because it is not rare that I have to re-open an already viewed file to double check something, or get context again. In this case, I need to unfilter, find the file again, etc etc
• Compactness: The vertical spacing between the file and folder names in the tree is really too big IMO, so that even for rather small PRs with 5-6 files in it I have to scroll in it to see it all, which is a bit ridiculous.

Thanks for the effort, it is really appreciated, but to be honest I think it needs some finishing touches before being fully functional. Until then I guess I'll be staying with my chrome extension.

[i2van]

When this feature will be available for enterprise users?

[Nuttapon43]

I'm so sorry for the loss of my friend