Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 347928 - Open git commit viewer from 'Changes' section
Summary: Open git commit viewer from 'Changes' section
Status: CLOSED MOVED
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: Mylyn (show other bugs)
Version: unspecified   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: helpwanted
Depends on:
Blocks:
 
Reported: 2011-06-01 08:53 EDT by Sascha Scholz CLA
Modified: 2011-06-05 19:02 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sascha Scholz CLA 2011-06-01 08:53:08 EDT
A Hudson build which was triggered by a git SCM change displays the change summary in the 'Changes' section.

double-click the change summary:
* Current behaviour: Open task dialog is opened asking "Unable to match task. Open Repository Task dialog?"
* Expected: Open change in EGit commit viewer (old behaviour as fallback?)

double-click on a file in the change:
* Current behaviour: Error message "The selected file is not available in the workspace" probably because project name doesn't match path in repository
* Expected: If Egit repository containing the commit is available use EGit to open the right file (like commit viewer does, EGit does know which project is shared with which repository, old behaviour as fallback?)
Comment 1 Steffen Pingel CLA 2011-06-05 12:10:01 EDT
These suggestions sound very good to me. I am not sure about the default behavior for double click  on change sets since linking to tasks is key to our traceability model but having an option to navigate to the EGit commit viewer definitely makes sense to me.
Comment 2 Benjamin Muskalla CLA 2011-06-05 17:47:27 EDT
Hm. I'd suggest that Mylyn Build provides a proper popup menu id and let EGit contribute the corresponding action (in my eyes, this is the right direction of dependencies). While EGit will likely not depend on Build (and in no way the other way around), we could think of having the ID in versions and let team providers contribute proper actions for all changesets managed by Mylyn (eg. builds, reviews, whatever).
Comment 3 Steffen Pingel CLA 2011-06-05 19:02:06 EDT
If this is not possible through the team API the Mylyn Versions project should provide the required abstraction for opening commits. The Mylyn EGit Connector is intended to work as a generic bridge that doesn't couple to specific Mylyn sub-projects to avoid the need for a Mylyn EGit bridge for every single component (i.e. Tasks, Context, Builds, Reviews...).
Comment 4 Eclipse Webmaster CLA 2022-11-15 11:45:08 EST
Mylyn has been restructured, and our issue tracking has moved to GitHub [1].

We are closing ~14K Bugzilla issues to give the new team a fresh start. If you feel that this issue is still relevant, please create a new one on GitHub.

[1] https://github.com/orgs/eclipse-mylyn