Pull Requests

[shana]

Imported from https://github.com/github/VisualStudioInternal/issues/428

So this is the broad list of things that go into PRs. I've set checkmarks on the bare minimum PR support without which there's probably no point in shipping. Any things that we wouldn't support initially would instead jump to the website to show the information, if possible.

PR Feature - Level 1

• [x] List Pull Requests
  • [x] Filtering
• [ ] Create Pull Request
  • [x] Entry form for title, description and create button
  • [ ] Assigment
  • [ ] Commit list

    PR Feature - Level 2

• [x] Create Pull Request
  • [x] Commit detail (file changes list per commit)
  • [x] File changes list (of the PR)
  • [x] Diff of file change selected (from commit detail or PR changes detail), no special adornments

    PR Feature - Level 3

• [ ] Pull Request detail
  • [ ] Commit list
  • [ ] Commit detail (file changes list )
  • [x] File changes list (of the PR)
  • [ ] Conversation list
  • [x] Diff of file change (from commit detail or PR changes list)
  • [ ] Add comment on diff view line
  • [ ] See comments on diff view line
  • [ ] Merge PR
  • [ ] Close PR

    Things to figure out

• [ ] Need a way of assigning someone to a PR
• [ ] Need a merge button somewhere
• [ ] Sorting

  Mockups

  Pull Request List

Pull Request Creation / Detail

The pull request creation wouldn't have a Conversation tab because, well, it's a new PR, but viewing an existing PR would have it. Still debating whether to use tabs or dropdowns (for space conservation), but tabs do provide useful information.

Not seen in the mockups is the ability to see individual changes list per-commit, which is a very useful feature. Considering having the commit entry as a collapsible pane that shows a list of changed files in the same way as the PR file change list.

Pull Request Detail, alternate form with pull downs

[kevinsawicki]

/cc @github/atom

[simurai]

Still debating whether to use tabs or dropdowns (for space conservation), but tabs do provide useful information.

If space allows it, tabs would be nice. Better for orientation and quicker to access the different sections. Maybe the tabs could do without the icons? I tried it out here:

Also added:

• Create + Merge PR button
• Build check + conflict status
• A way to go back to the PR list. Could be just the back buttons at the top. Or the bread crumbs. Or a "cancel" button?

[shana]

/cc @Haacked @orderedlist

[shana]

actually, /cc @github/desktop for the :eyes:

[shana]

Thanks for this, looks great!

For reference, this is the UI we have currently on the Team Explorer tab (pane on the right side with yellow highlighted button). It's the main "page" that shows up when you click on the Team Explorer tab, and contains several navigation items (some or ours and some aren't). The Pull Requests navigation item is ours, and it's currently set to open up the pr page on the website. The plan is to use this navitem to open the PR feature in the GitHub pane. In the future, other features (like Issues) can be added to the GitHub pane (that's the plan, anyway :smile:)

A way to go back to the PR list. Could be just the back buttons at the top. Or the bread crumbs. Or a "cancel" button?

The PR icon on the toolbar on top of the pane is meant to be used as a shortcut to go back to the main PR view (which would be the list with whatever filters have been set by the user). This is a UI pattern that some bits of VS are introducing (toolbar with icons that switch between features in one pane, with back and forward buttons to navigate between areas of a particular feature), but it's not very common, so not sure how easy it is for users to pick up. Breadcrumbs could work alongside that, they're definitely easier to understand.

[simurai]

The PR icon on the toolbar on top of the pane is meant to be used as a shortcut to go back to the main PR view

I see. And yeah.. when there are more features like Issues, it will have its own icon up there.

I saw that other than the Team Explorer, it looks very close to GitHub for Windows. Like the login, clone and create repo popups. So here a version that is closer to that. Like the buttons have the circled checkmark:

Although not sure. That style works well when there is padding and white space available. But in that side panel where there is lots of stuff and that can be resized, those buttons get a bit lost.

[shana]

Although not sure. That style works well when there is padding and white space available. But in that side panel where there is lots of stuff and that can be resized, those buttons get a bit lost.

I really like the PR status icon on this version, fits in much better than the green-background one!

In terms of using the circular buttons, yes, these panes have different size constraints that can make it hard to have that much padding. Not only is it a problem with horizontal space, but vertical space is somewhat at a premium too - the mockups were done on a big monitor, so even though I didn't take them with VS on full screen, I still have a lot of vertical space there, other users can have less space.

The panes are scrollable, but action buttons should be positioned so they don't disappear off screen if scrolling is required, so people don't get confused about how to do things. Any extra space that buttons take is less space for other information and more potential for scrolling.

P.S.: let me know if my mockups PSD would be useful, I can send it to you.

P.P.S.: Also, I'm doing a road trip thing, which is why my replies are somewhat slow, sorry about that :-/

[simurai]

but vertical space is somewhat at a premium too

Yeah, also saw that vertical space can get split up with another "Properties" panel. Ok, how about smaller "Windows" style buttons, but the merge button is green:

P.S.: let me know if my mockups PSD would be useful, I can send it to you.

So far I'm fine, thanks. I started to rebuild it in Sketch. The font rendering doesn't 100% match like in Windows, but should be close.

[simurai]

Need a way of assigning someone to a PR

How about under the branch picker:

[simurai]

Commit detail (file changes list per commit)

Clicking on a commit would expand the item and show the file list (per commit). Clicking again would collapse the item.

[simurai]

Diff of file change selected (from commit detail or PR changes detail), no special adornments

I guess selecting one of the changed files would open the code diff view in VisualStudio. Something like this:

Maybe the file list items need a selected state.

---

Diff of file change (from commit detail or PR changes list)

• Add comment on diff view line
• See comments on diff view line

Does VS allow to add/see comments inline in the diff view? Or do the comments need to be shown in the GitHub panel?

[shana]

For the merge button, I would probably dock the whole thing to the bottom of the panel, so comments get their own scrolling space. I was also thinking about having it always visible no matter which view you're looking at (commits, conversation or file changes), something like the screenshot below. I would love to be able to collapse the comment box so that it doesn't occupy so much space while just being there, and only expand when the user clicks on it, that could work nicely.What do you think?

I'm thinking that the merge button might need a confirmation of some sort, it's a destructive operation and users will certainly hit the button by mistake. Maybe built in to the button itself, so it requires two clicks (that way accidental clicks will be safe but users can still merge without going through extra popups).

I guess selecting one of the changed files would open the code diff view in VisualStudio. Maybe the file list items need a selected state.

Yup, that's the plan. Any item in a file change list should be selectable and show the corresponding diff. The mockups I posted don't show it but I switch to a darker background for selected lines.

Does VS allow to add/see comments inline in the diff view? Or do the comments need to be shown in the GitHub panel?

The plan is to have comments inline, yes. Whether it's using the built-in diff view, or whether we do our own view with diff and inline comments, I'm not sure yet, but at the end, line comments should be showing up in the diff, like we do on the website.

[haacked]

I'm thinking that the merge button might need a confirmation of some sort

Yeah, we should do it the same way github.com does it where the button turns into a confirm merge button.

[simurai]

I was also thinking about having it (merge button) always visible no matter which view you're looking at

Was thinking that too, but then I wasn't sure anymore because it might be a good thing to have the merge button only after the last comment. It makes sure you're aware of any last minute changes. Otherwise you might miss a "ohh.. just noticed "something", I'll try to fix that." I wonder if there is a specific reason why the merge button on github.com is at the end of comments and not somehwere at the top or side bar?

I would love to be able to collapse the comment box so that it doesn't occupy so much space while just being there, and only expand when the user clicks on it, that could work nicely.

Yes, that would be nice. Maybe initially just have space for 2-3 lines.

[shana]

I wonder if there is a specific reason why the merge button on github.com is at the end of comments and not somehwere at the top or side bar?

On the website there's many actionable contexts - a page contains general repo information, buttons to other areas, settings, links, etc etc - any button that acts on something specific needs to be close to that specific thing, and the central column on the website is where actions for the content go - so the merge button has to be in the center along with its comment box, and can't be on the sidebar. It could be above the comments, but then the reason you mentioned probably comes into play - you don't want people merging without reading all the comments.

I would prefer not to have the merge button and comment box scrolling up along with the comments, that's not something that happens normally in a native app and people will get confused (or won't find the thing because they will never remember to scroll, or they'll get a cut up comment box because things almost fit the screen but not quite). If there's a ton of comments I've already read, scrolling down all the way to the end is going to be a pain, too.

So there's two issues that need to be handled in the UI in a smart way - how to let the user know that there's new comments (possibly before letting them merge? automatically scrolling to the new comments and highlighting the background?), and how to easily navigate a potentially large list of comments (I'm already only showing the first line or two of a comment on the list, maybe that's enough? do we need more than just a scrollbar?)

[simurai]

I would prefer not to have the merge button and comment box scrolling up along with the comments

:+1: Yeah, I can see that could be annoying having to scroll them into view first.

how to let the user know that there's new comments

Green indicator dot? New comments would be green too:

how to easily navigate a potentially large list of comments (I'm already only showing the first line or two of a comment on the list, maybe that's enough? do we need more than just a scrollbar?)

Maybe some sort of limit still needs to be there? Just as a security in case there are thousands of comments. It could show the initial 100 and then you have to load more:

Or even with some pagination? Usually when I go to a PR (or issue) with a lot of comments, I'm most interested in the beginning and the end. The beginning because it explains the context of the PR. And then the end to see if the conversation is still active or if a conclusion is reached etc. Pagination would make it easier to skip the middle and go straight to the end of the list. Here just a simple dots version:

Some more random ideas to leave more room for scrolling:

1. Like browsers on smartphones hide tool/address bar when scrolling down.. scrolling down on the comments would hide the merge button and comment input, leaving more room to read the comments. When scrolling stops or once reached the bottom, the merge button and comment input would appear again.
2. Remove the "Comment" button. It would save some space. Submit is on [enter]. You could still do a line break with [shift + enter], but it's more for short single-paragraph comments.

2b. Or maybe better.. I think you've already mentioned it.. have a small comment input only, but then when focusing on it, the comment input (box) expands and also a comment button appears.

[kevinsawicki]

/cc @fabianperez

[ghost]

I am really interested in the way a PR is associated with an Issue. This is a painful process that can save us a lot of time if it's automated. Ideally our team would like to be able to create a pull request and link to an issue from the same repo or a different repo. We work on 2 repos at the same time i.e our solution consists of 2 projects and each one is it's own repo (think one for our app framework and one for the specific app we are building). Both repos can have issues. Most features require 2 pull requests to be submitted (changes are required both in the framework as well the app for any given feature) and they always link to the same issues. Since currently an issue can exist in one repo only this means that one of the pull requests will need to link an issue from a separate repo.

I'd really appreciate it if you took this suggestion under consideration.

P.S We use GitHub Enterprise.

[shana]

@ToMaHaWk What would you want automated when you link a PR with an issue on a different repo? Do you just want the mentions, or do you want it closed when the PR is merged?

[donokuda]

:art: :art: :art: :art: :art:

List of pull requests

Here's a mock-up listing opened and updated pull requests. Continuing what @simurai and @shana discussed earlier, we indicate new pull requests with a green dot next to the avatar of the author. Any pull requests with new comments or changes are indicated with a green dot next to the comments count.

You'll be able to view the details of each PR in Visual Studio once we implement that feature. In the meantime, clicking on the title of the pull request will open up it on GitHub.com in the browser.

Sometimes you'll want to see some details related to each pull request (such as assignee, labels, tasks, etc.) You can find those by toggling the details dropdown:

We'll sometimes want to filter our pull requests by what's opened or by assignee. You'll do that through the filter menus. Right now I only have opened, assignee, and author as filter options. If we want to include more, I'll need to think of a better layout to fit them.

Creating a new PR

You'll start creating a pull request by clicking the New Pull Request link and entering the title and description. Clicking on a commit underneath the form could bring you to the commit's detail in the built-in Visual Studio git client.

You could specify which branch you want to merge into using the dropdown near the title field.

Down the line, we'll want to be able to assign individuals to review a pull request. We'll do that through the Assignee selection.

The version above uses a simple menu. It would be interesting to see if it's possible to have a menu with the ability to filter people. This is especially for organizations and teams with dozens of members.

[shana]

This is so awesome, I love it!

The version above uses a simple menu. It would be interesting to see if it's possible to have a menu with the ability to filter people. This is especially for organizations and teams with dozens of members.

Yup, definitely possible!

[shana]

So let's start with the PR list. Do we have a preferred font we want to use? Right now I'm using Segoe UI with a font size of 14 for the pr title.

The icon you're using for the comments is the comment_discussion octicon, right? What size should it be rendered at?

[donokuda]

Yup, definitely possible!

Sweet! I can create a hi-fidelity mock for that UI component. I wasn't able to find a similar one in Visual Studio but I found noticed a similar pattern used in our desktop app.

So let's start with the PR list. Do we have a preferred font we want to use? Right now I'm using Segoe UI with a font size of 14 for the pr title.

Segoe UI is exactly what font I've been using. Excellent :eyes: with the font sizes: I've also been using 14 for the title and 12 for the details. I prefer staying close to the fonts natively used so our extension doesn't feel out of place.

The icon you're using for the comments is the comment_discussion octicon, right? What size should it be rendered at?

Yup! I've been using 16px for the Octicons as a minimum since the Octicons have optimized the vectors for that size.

[shana]

Yup! I've been using 16px for the Octicons as a minimum since the Octicons have optimized the vectors for that size.

Awesome! Do we have a set color for the green icon indicator? Right now I'm just setting it to "Green", is there a specific RGB that we use?

Also, the back and forward icons that I'm using on the toolbar don't look the same as the ones everywhere else in VS because I'm using a xaml vector while most of VS uses a bitmap. I'd really like to keep using the xaml (it scales nicely), but can't find ones that match the more slimmer icons VS uses (compare the back icon on the PR creation view toolbar with the one on the PR list view - the list view is my xaml icons while the creation view have icons I copy-pasted from VS screenshots iirc). Are we happy with the fatter xaml icons, or should we use octicons (which aren't round, if that matters), or create new ones?

Same with the refresh icon, actually. I don't think we have a refresh octicon and the one in the toolbar currently is a stub I found somewhere. Should we do our own?

[donokuda]

Awesome! Do we have a set color for the green icon indicator? Right now I'm just setting it to "Green", is there a specific RGB that we use?

Let's use the colors specified in PrimerCSS. In this case for green, the RGB will be R: 108 G: 198 B: 68

I'd really like to keep using the xaml (it scales nicely), but can't find ones that match the more slimmer icons VS uses (compare the back icon on the PR creation view toolbar with the one on the PR list view - the list view is my xaml icons while the creation view have icons I copy-pasted from VS screenshots iirc). Are we happy with the fatter xaml icons, or should we use octicons (which aren't round, if that matters), or create new ones?

I like the idea of using our octicons whenever we can since they fit our branding and we have access to the vectors. However, would having differently styled navigation icons in the toolbar be jarring for Visual Studio users? Should we strive for interface consistency or brand consistency? I'm leaning towards brand but would love your thoughts on that matter.

Same with the refresh icon, actually. I don't think we have a refresh octicon and the one in the toolbar currently is a stub I found somewhere. Should we do our own?

I don't believe we have one. I'll check with the octicons team. EDIT: in the meantime, feel free to use a stub and we can swap it out.

[shana]

I like the idea of using our octicons whenever we can since they fit our branding and we have access to the vectors. However, would having differently styled navigation icons in the toolbar be jarring for Visual Studio users? Should we strive for interface consistency or brand consistency? I'm leaning towards brand but would love your thoughts on that matter.

Great question - I honestly am not sure. I'm leaning towards the brand image myself, it would be nice to be distinctive in our own space. @Haacked, thoughts?

[donokuda]

Great question - I honestly am not sure. I'm leaning towards the brand image myself, it would be nice to be distinctive in our own space. @Haacked, thoughts?

The answer to this will also inform the answer around the refresh icon :smile_cat: :repeat:

[donokuda]

Here's a pass at a tooltip dropdown:

A quick breakdown of states:

Filter would work close to how GitHub currently does:

• By default, your username is on top. Everyone else is listed in alphabetical order
• When you assign someone, their username is checked and is listed below your name
• Clear assignee option appears when someone is assigned

Would love a gut check on this direction, @simurai @shana. This direction is a bit custom to Visual Studio so I want to make sure it still feels like it fits at home. Also would like some insights into the engineering effort for custom UIs and balance nice-to-haves (aesthetics) with need-to-have (experience.)

If this is :+1: I can spec out any dimensions/colors as needed.

:exclamation: Side note - I changed the "Assignee" label from bold to regular since we're (edit: already) differentiating between the label and the selection by color. :flushed:

[simurai]

Looks great. :+1:

When you assign someone, their username is checked and is listed below your name

Would the "listed below your name" only be shown when re-opening the dropdown? Otherwise it might be confusing if a name disappears when you're scrolled to the bottom and select somebody.

[donokuda]

Would the "listed below your name" only be shown when re-opening the dropdown? Otherwise it might be confusing if a name disappears when you're scrolled to the bottom and select somebody.

Pretty much. I'm thinking that when a user is selected from the menu, the menu will close and the user will be selected. That way we won't have to reorder or maintain the position of the names.

[shana]

I really like the look of these dropdowns. We're a bit constrained on what we can get away with UI-wise in the Team Explorer pane (because it's not a space we control), but in our own pane I'm all for creating our own look, and these dropdowns feel great. As a VS user, I don't find this design jarring at all.

@shiftkey @niik What do you feel, as VS users, about these latest mockups?

[alexangas]

Sorry to butt in... Should "Clear assignee" be made a little more discoverable? The user is perhaps more likely to be in the mind frame of thinking about adding more assignees when using that drop-down, not removing them.

Another possibility might be to take that option out of the dialog and put something like a cross icon between the name and the drop-down icon? Like the common UI for removing tags.

[shana]

@arangas Good point, one dropdown mixing two different intents might be confusing.

[donokuda]

Sorry to butt in... Should "Clear assignee" be made a little more discoverable? The user is perhaps more likely to be in the mind frame of thinking about adding more assignees when using that drop-down, not removing them.

Another possibility might be to take that option out of the dialog and put something like a cross icon between the name and the drop-down icon? Like the common UI for removing tags.

Good point. As far as I know, our API supports one assignee at a time, but I agree that it might be confusing to hide "Clear assignee" in the dropdown. I like the idea of using a tag-like UI, but I'm concerned about having two clickable targets fairly close to each other (especially if one of the actions is destructive by removing the assignee):

Maybe it makes sense to expose the action on the side when there is an assignee:

[alexangas]

@donokuda Good point, that would be better.

[donokuda]

@arangas :+1: We should go with that pattern for the assignee. Thanks for the :eyes: and the feedback!

[shiftkey]

What do you feel, as VS users, about these latest mockups?

They feel familiar enough coming from dotcom, and should fit nicely into the VS experience so I'm :thumbsup: with heading down this path.

I couldn't find a good example of this unified search + listbox view already present in VS (some do one, or the other) but we use similar patterns in GitHub Desktop (for example, selecting an ignore template) so I'll go to war here to ensure we can do the same thing here :grin:

@niik might have some more UX insights as I think he was involved a bit with the initial extension work

[donokuda]

I couldn't find a good example of this unified search + listbox view already present in VS (some do one, or the other) but we use similar patterns in GitHub Desktop (for example, selecting an ignore template) so I'll go to war here to ensure we can do the same thing here

Yeah, I also couldn't find an example of that in Visual Studio and wasn't sure if I overlooked something. The aesthetic deviates slightly away from GitHub desktop and is a little closer to dotcom, but here's a version closer to GHD for fun (the squares are placeholders for avatars:)

In retrospect, it makes more sense to make these GHD and GHfVS components similar so we can, at the very least, reuse code and designs between the two.

Thoughts?

[shiftkey]

This is the one I was referring to earlier:

In retrospect, it makes more sense to make these GHD and GHfVS components similar so we can, at the very least, reuse code and designs between the two.

More sharing of styles is totally :thumbsup: with me. And if this is a chance for us to give Desktop a bit of spruce up "for free" then let's see what we can do...

[shana]

Yes, definitely let's align styles across our desktop products as much as possible ^_^

I really like this. I definitely have a soft spot for the [bold] [subdued] style of showing information.

---

@shiftkey Maybe it's a good idea for me to implement these new styles in a separate library? Right now I have a GitHub.UI and a GitHub.UI.Reactive (for technical reasons based on dependencies), which are slimmed down versions of what GHD has. But! We could avoid copy-pasting things across projects if stuff that we deem shareable would go into a separate library (GitHub.UI.Shared?)

[donokuda]

Yes, definitely let's align styles across our desktop products as much as possible ^_^

I also want to create a styleguide for us as a reference of what components we have, which should also help us prototype new features and flows... But that's a discussion outside of this issue :smile:

@shiftkey Maybe it's a good idea for me to implement these new styles in a separate library? Right now I have a GitHub.UI and a GitHub.UI.Reactive (for technical reasons based on dependencies), which are slimmed down versions of what GHD has. But! We could avoid copy-pasting things across projects if stuff that we deem shareable would go into a separate library (GitHub.UI.Shared?)

Love this idea too!

@shana What are your thoughts on the existing filter dropdown @shiftkey referenced?

I don't mean to continue bikeshedding this component but if we have something that already exists and we can extend, then I'd rather go that route. :bike: We can still adjust it so that follow the same type treatment ([bold] [subdued]) in my version

[shana]

I'm not a fan of the separator lines, to be honest. They clash with whatever happens to be in the background very easily. Also something about the left alignment of the entries and the filter text box is annoying my brain, for some reason.

With that said, they're two different boxes with two different purposes and amount of information, so I'm not sure I can compare them directly. I was going to, but refrained because one has single word entries while the other has avatars and multiple word entries, they fill up differently.

[shiftkey]

@shana

Maybe it's a good idea for me to implement these new styles in a separate library? Right now I have a GitHub.UI and a GitHub.UI.Reactive (for technical reasons based on dependencies), which are slimmed down versions of what GHD has. But! We could avoid copy-pasting things across projects if stuff that we deem shareable would go into a separate library (GitHub.UI.Shared?)

Yep. Feel free to repurpose whatever from GHD, and I think a *.Shared is a good convention for us.

Also, I'm concerned about the lack of @niik in this thread. Maybe if I say his name three times he'll appear - @niik @niik @niik?

[donokuda]

Also something about the left alignment of the entries and the filter text box is annoying my brain, for some reason.

I'm willing to bet your brain really wants the placeholder text and the list text to align, but the list text is aligning with the input box instead.

With that said, they're two different boxes with two different purposes and amount of information, so I'm not sure I can compare them directly. I was going to, but refrained because one has single word entries while the other has avatars and multiple word entries, they fill up differently.

That's a good point. I was comparing them because of their similar UX around filtering in a list. But when I think about the content that could live in there, the filterable list without separator lines is more flexible for grouping content. A good example in GHD is the branch picker:

(Also note the [edit: alignment] of the placeholder text and the list text)

[shana]

Aaaaaaaahhh yes that's totally it. Messing up my brain so much!

Your list mockup and the GHD one are pretty close. The only difference is the alignment of the subdued text and the boldness of the other text. The boldness on your mockup matches what we already do in the Connect area to list repositories (because it's a thing MS also does). I find that the dates aligned to the right on the GHD branch picker work well, but in the case of the list of names mockup it works better having them aligned to the left next to the username. I have no problems making a variation on the GHD one for VS, but these are minor things, really, and I defer design decisions to the experts :smile:

One thing to consider is that we need a dark theme. VS ships with one by default and all the panes need to follow it, otherwise it'll look horrible. We can get away with the dialogs because they're not inside the VS UI, but we can't avoid it with panes.

[shana]

But omg please let's match the left padding of the text to the inner padding of the filter box, that breaks me so much!

[donokuda]

I find that the dates aligned to the right on the GHD branch picker work well, but in the case of the list of names mockup it works better having them aligned to the left next to the username.

Agree. With the name right-aligned in the pop-up, if someone wanted to know a user's real name in the dropdown, their eye would have to jump to the right side. Plus we would end up hiding information when a user is selected.

One thing to consider is that we need a dark theme. VS ships with one by default and all the panes need to follow it, otherwise it'll look horrible. We can get away with the dialogs because they're not inside the VS UI, but we can't avoid it with panes.

Good call! This is also important as we think about using color to convey information.

[donokuda]

Noodled on some thoughts around the UX of listing changed files in the commit tab.

Clicking on a commit would expand the item and show the file list (per commit). Clicking again would collapse the item.

– https://github.com/github/VisualStudio/issues/20#issuecomment-127841125

If we were to click on a commit, would the expected behavior be showing the file list or showing the details of the commit itself?

My expectation is that it would show the details of that commit in the team explorer, if possible:

If that's the case, we could toggle the list of files by clicking the counter on the side:

However, I'm concerned that this is a UX pattern not used anywhere else. Maybe we consider using a list dropdown instead?:

Also, we could truncate long directories and filenames and show the full path in a tooltip:

Clicking on the filename could open a diff view comparing the file, at that commit, to the target branch. However, I'm wondering if this is a common action when creating a PR.

[shana]

Jumping to Team Explorer for the commit info view might be confusing - it jumps to a different pane, how is the user getting back to our pane (back doesn't work, the navigation is only between Team Explorer pages, not everything else)? Not sure I can actually load a specific commit information programmatically on Team Explorer, either. We might need to have a commit detail page to show this information.

:+1: on the dropdown to show the file list, it's nice. Showing the individual diffs might not be the most common action when creating a PR, but it is when looking at existing PRs, and the views here are pretty much the same for either, so we can support it in the creation too.

[donokuda]

Jumping to Team Explorer for the commit info view might be confusing - it jumps to a different pane, how is the user getting back to our pane (back doesn't work, the navigation is only between Team Explorer pages, not everything else)?

Totally. I agree that jumping to a different pane doesn't make it clear where we came from and how to get back unless you look for very specific cues (such as the tabs changing.)

We might need to have a commit detail page to show this information.

I started a wireframe concept around this for our pane, keeping in mind that I'm making assumptions of what information is useful to show here: