Community
Participate
Working Groups
RC1 candidate, orion.eclipse.org When looking at the diffs for a particular commit, I find myself always having to scroll to the right to get the diffs command (or else size commit detail to be bigger than I would like). It would be more useful if the diff command appeared to the left of the file name so that I could use it. Also, we are showing the diff command only on hover. But there is no affordance (such as the actions column) to help me know where I might need to hover in order to find the diff command. Ideas: Put a compare icon next to the modification icon. Or...use the compare icon instead of the modification icon.
Created attachment 204895 [details] screenshot
I'd like to expand the scope of this bug to discuss the presentation of commits in general. They are a first class concept in git but we use a very transient presentation to show them, and the presentation requires a lot of clicks to get to the point where I can really see what the commit is about. Consider a commit that changes more than one file. To see what the changes were, I have to - click to open the details pane - size it to make sure the diff commands can be used - ctrl-click each diff Further, a lot of the real estate in the details pane is used for information I can see on the left hand side (author name, commit message, etc.) If, instead, the git log just had a link to the commit, you could open a page that shows the commit details, but also shows the changes in each file, with a command to open the side by side compare page if needed.
Created attachment 205931 [details] rough mockup very rough...trying to show proof of concept. Not sure how the scrollbars within scrollbar approach would really work. If only one file changes we want to give it all the real estate, etc.
Created attachment 205932 [details] fixed toolbar i had the wrong toolbar in the mockup, this one shows commit-related commands
(In reply to comment #4) > Created attachment 205932 [details] > fixed toolbar Looks nice, I would add an outline view if there is more then one file changed and made sections for each file expandable (collapsed by default). What "open editor" action is supposed do? If it's for opening the current version of the file maybe we could convert its name into a link? Or leave the action and use the link to expand diff section for the selected file.
(In reply to comment #5) > (In reply to comment #4) > > Created attachment 205932 [details] > > fixed toolbar > > Looks nice, I would add an outline view if there is more then one file changed > and made sections for each file expandable (collapsed by default). +1. I was imagining that those sections could expand and collapse. We can tinker with the default, I would imagine if it's a small number of files, having them expanded is okay... > > What "open editor" action is supposed do? If it's for opening the current > version of the file maybe we could convert its name into a link? Or leave the > action and use the link to expand diff section for the selected file. Yes, I was imagining it as a link. I wrote that comment in the mockup at the very end and didn't go back to show it. But yes, a link on the file name would probably be enough.
also, I'm not sure about the title/breadcrumb content...we can tinker with what to show depending on what one might want to link back to from looking at a commit
(In reply to comment #7) > also, I'm not sure about the title/breadcrumb content...we can tinker with what > to show depending on what one might want to link back to from looking at a > commit Right, the current "884d09d0f...org.eclipse.orion.client" doesn't make much sense. It should rather say "{parent of 884d09d0f}..884d09d0f" so you now exactly what you're looking at. Other links I think can be useful: * We could add Parent(s) and Child/Children links to the commit summary. * Bug 361293 should be clickable as well. We already do this in Git Log. * mamacdon@ca.ibm.com could be a "mailto:" link or even better "Ping via sametime"[1]. Of course only for those who use sametime. * A link to full log of the branch the commit is on would be handy. If it's a commit on a local branch and it hasn't been pushed yet we could indicate it somehow. The same for a commit on a local branch which hasn't been merged. On Git Log we do with with arrows, could you them here too. Last but not least, add commit date and tags (if any exist) to the summary. [1] see the link http://faces.tap.ibm.com/#uid:087058649/Mark%20MacDonald after expanding "more info"
Oh, one more thing: if that's the last commit on a local, active branch we could add the "Amend" command to the toolbar, which would take us to the Git Status page with the Amend checkbox already selected.
(In reply to comment #2) > If, instead, the git log just had a link to the commit, you could open a page > that shows the commit details, but also shows the changes in each file, with a > command to open the side by side compare page if needed. Having a separate commit page sounds right. The tray was meant as a minimal view on the commit details and I think there is still a place for it. If you want to see basic details you would use the tray, for the full view, you would click on the commit and open the commit page.
Wow, what great ideas... (In reply to comment #10) > Having a separate commit page sounds right. The tray was meant as a minimal > view on the commit details and I think there is still a place for it. If you > want to see basic details you would use the tray, for the full view, you would > click on the commit and open the commit page. Yeah, I was thinking last night that I might want to be able to quickly see which files are affected before I decide that I need to see all that detail. I was thinking about hover preview, which is kind of what the tray serves with that bouncing open. If we keep the tray I think we want to work on the affordance for it (since clicking a commit would open the page vs. opening a tray).
(In reply to comment #11) > Yeah, I was thinking last night that I might want to be able to quickly see > which files are affected before I decide that I need to see all that detail. I > was thinking about hover preview, which is kind of what the tray serves with > that bouncing open. If we keep the tray I think we want to work on the > affordance for it (since clicking a commit would open the page vs. opening a > tray). I was thinking about this too, and I kind of like the hover. We aren't currently using hover for anything useful here and it seems like a good fit. Clicking would then open the page. I think we definitely need *something* on that page to see the list of files, because a common workflow for me is scanning through the log to find commits that might be related to a particular problem, etc. If I had to open a new page on each commit just to see the list of related files it would be slow and painful. If I want to review a particular commit in more detail then the separate page looks nice. If a commit touched a massive list of files we might have to limit how many compares we show per page.
another advantage of a hover. In the "mini logs" in the git status page, I often want to see the same kind of commit summary (especially the commit SHA if i'm updating a bug report to say I just pushed something). Right now I have to go to the log in order to get the tray. If we had a summary hover for a commit, I could get that information from anywhere, not just a page that had a tray.
(In reply to comment #13) > I could get that information from anywhere, not just a page that had a tray. +1 from me for using hovers instead of trays. At least for commit details.
First cut pushed as 14f67c307e067cfbf779f5e994423691928ceaaf. To open the page, click on a commit in the Git log and then, in the details pane, click on the commit's Name. In the future I will remove the pane and go straight to the details page. The page is extremely simple at the moment, but I will be adding more features in the nearest future, so leaving the bug open. The good news is that you can now remove a tag on the new page (bug 346286).
(In reply to comment #15) > To open the page, click on a commit in the Git log and then, in the details > pane, click on the commit's Name. In the future I will remove the pane and go > straight to the details page. We should leave the pane for now. As discussed with Susan, we may replace it with a popup view showing the most important commit details. So once the commit page is ready, we may think if we could just display its minimal version in a popup instead of the tray. This is a separate bug though, see bug 367409.
(In reply to comment #16) > (In reply to comment #15) > > To open the page, click on a commit in the Git log and then, in the details > > pane, click on the commit's Name. In the future I will remove the pane and go > > straight to the details page. > > We should leave the pane for now. As discussed with Susan, we may replace it > with a popup view showing the most important commit details. So once the commit > page is ready, we may think if we could just display its minimal version in a > popup instead of the tray. This is a separate bug though, see bug 367409. I agree with both of you ;-) The commit link should take you to the commit details page, so the pane will go away. Having some summary info in a hover is a good thing.
The page contains the most important commit details now. It is linked from the new Repo page and from the Log page. I'm closing this bug and will open new bugs for further enhancements in this area.
.
