Community
Participate
Working Groups
I've got several repos cloned from github.com. The Repositories page is far better then it used to be, the only thing I'm missing at the moment is being able to go to a cloned repo page on the github.com. We have a script allowing to clone a github repo into Orion (bug 359080), this is kind of link back. Simple URL parsing should be enough: * git@github.com:zaza/mockups.git > https://github.com/zaza/mockups * https://zaza@github.com/zaza/mockups.git > https://github.com/zaza/mockups * git://github.com/zaza/mockups.git > https://github.com/zaza/mockups
This is not an issue specific to GitHub. For example I might want to navigate to: http://git.eclipse.org/c/platform/eclipse.platform.ui.git Which is the web page for this remote: http://git.eclipse.org/gitroot/platform/eclipse.platform.ui.git Maybe we could consult a property on the remote where we store the web address (if any) for that remote.
(In reply to comment #1) > Maybe we could consult a property on the remote where we store the web address > (if any) for that remote. I was rather thinking about something similar to our URL scanner. We should define a service that provides web page URLs for recognized remote URLs. GitHub and GitEclipse cases mentioned above are easy, so we can provide plug-ins that translate URLs, but for more complicated cases Git providers could provide such plug-ins. Moreover the service could provide more metadata for repos which is not available in local clones (like description).
This is exactly where I would like to see "orion.page.links.related" extension point go (The "Related pages" menu). Currently we have related links extensions that just reuse a command, so you can do things like hook git log to the editor page. What we are missing currently is a way to get the metadata you need in order to validate the command and produce the link. For example - from the editor, get full metadata on the parent folder, and from that, derive links to git status, github, etc. - likewise...any links found in the links extension on a page should show up in "related pages" I don't think we need a new extension point, but rather grow "orion.page.links.related" so that it's not solely based on commands, but that contributors can define new kinds of mappings. And key to this is the ability to get metadata in the background so that we don't have to already be on a page with the remote location known before we can jump to a related link.
I released some initial support. I think having these kinds of links, especially to external places, are important for helping show our vision for a "linked IDE." I'm hoping Tomek, Gosia, or Szymon is inspired to make this even better. Here's how it works: 1) There is an extension "orion.page.links.related" that in its simplest form is just a command id. (in fact that's all that's supported right now.) For exmaple see the contributions in gitPlugin.html 2) In globalCommands, we process this extension point, looking for the commands on the page. If a command is there, we try to apply them to the page's item. If they fit, they go in the "related pages" menu. What triggers this is calling mGlobalCommands.setPageTarget(someItem, registry, commandService) I added these calls to the commit page, repo page, log page, etc. 3) If you are afraid you are going to get a command that is basically your own page, you can use something like this. (this is from git log) mGlobalCommands.setPageCommandExclusions(["eclipse.git.remote", "eclipse.git.log"]); 4) So...to support this basic idea, I added two new commands in gitCommands.js: "orion.git.gotoEclipseGit" and "orion.git.gotoGithub" and I referenced these commands in an "orion.page.links.related" extension. It would be better if these commands had been contributed as navigator extensions in a plugin (rather than hard coded) but I wasn't sure that our validationProperties could do the parsing needed. (See bug 370903). So now you can see on the repo page (when there's a chosen repo)...you'll get a "related links" command called "Go to eclipse.org" etc... I was hoping that someone on the git side could flesh this out. What I see happening: 1) the commands are only contributed in gitCommands.createGitClonesCommands. I didn't want to copy them all over the place and wasn't sure where commands that belong on all git pages should go. It would be nice if "orion.git.gotoEclipseGit" and "orion.git.gotoGithub" could be run from the log page, the git status page, etc. 2) git status isn't participating in this stuff at all. It needs setPageTarget and setPageCommandExclusions set up on it 3) if we want these links to show up when the item on the page does not have a GitURL, but there is metadata that could get us to a GitURL, there is a trick where you can provide setPageTarget with a transform. For example, the editor does this so that if a related link is not supported on a file, its parent can be checked. This is how git status is available from the editor. mGlobalCommands.setPageTarget(metadata, serviceRegistry, commandService, function() { if (metadata.Parents && metadata.Parents.length > 0) { return fileClient.read(metadata.Parents[0].Location, true); } }); So maybe we could read additional metadata from a branch or remote if we want to map to the GitURL from somewhere that doesn't have one. If no one wants to look at this, please assign it back to me and I'll fumble through the git code. I think it's important that "Related pages" demonstrate that these aren't just Orion pages that we are linking up.
I should add that the parsing is not as flexible as what Tomek suggested...feel free to beef it up. Also, I couldn't test the github support because the GitURL was always the eclipse.org remote, even if I opened a commit from a github repo. So I think the visibleWhen functions might consider other properties (RemoteLocation?) and do other mappings. This is where I just wasn't familiar enough with the git metadata to do the right thing.
(In reply to comment #5) > Also, I couldn't test the github support because the GitURL was always the > eclipse.org remote, even if I opened a commit from a github repo. I have gotten the GitHub case working. Will push a fix shortly.
(In reply to comment #6) > (In reply to comment #5) > > Also, I couldn't test the github support because the GitURL was always the > > eclipse.org remote, even if I opened a commit from a github repo. > > I have gotten the GitHub case working. Will push a fix shortly. http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=cebf0d3b17d424997c155cc440dc3a4ef47ef6dd Note this is only for the case where the origin remote is at GitHub. If you have a repository whose origin is git.eclipse.org, but you added various GitHub remotes as well, this will not work. I'm not sure that can even work predictably - my orion.client has three remotes at github for example.
Szymon pointed out my previous patch didn't support all kinds of possible github.com URLs. I have released a more general solution: http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=0ceafddb598431acbae88ecf9bf6b8fda208b017
John should this bug be closed now?
We could close this bug and raise a new one for further work in .5 e.g. getting rid of hardcoded urls from gitCommands.js.
There is a lot more we can do here, and a lot of useful information in this bug that I don't want to lose. I'll leave this open and maybe next week find some time to split out some new bugs for remaining work.
I think this can be marked fixed back on what was done in 0.4, and the follow-in work in 0.5 in bug 370903. Links to remote git repository pages are now working on both the status and repositories page. The validation properties are generic, so any page with a "GitUrl" that matches the pattern for GitHub or git.eclipse.org will have the related link show up.
