Community
Participate
Working Groups
Currently Egit provides a very strong EGit integration. It currently does not support the integration of Github Pullrequests. Command line process is described here: https://help.github.com/en/articles/checking-out-pull-requests-locally Would be great if EGit would support to fetch Github pull requests as easy as Gerrit requests.
There is already code for some PR-related commands (checkout PR, merge PR, rebase PR), but I don't see them used anywhere in the code or in plugin.xml. Probably also limited to the GitHub HTTPS API. Looks like that part was never finished? I see two problems: 1. The refs/pull namespace is read-only, so you can't push new commits onto a PR that way. 2. How to detect that a repo is a GitHub repo? In the worst case the user might need to configure the clone explicitly, like it was once necessary for Gerrit, too. (We still have the "Gerrit Configuration..." command.) It might also be a self-hosted GitHub Enterprise server, so looking at the URL is not good enough. Querying whether the server advertises refs/pull/*/head refs might perhaps work, but might fail if there are other servers that happen to use the same namespace for something else. Gitlab EE uses refs/merge-requests/*/head,[1] Bitbucket Server uses refs/pull-requests/*/from and refs/pull-requests/*/merged.[2] Finally, working with pull requests isn't limited to GitHub. Would be nice if there was some general support. If this can be done simply via refs, it should also work over ssh. [1] https://docs.gitlab.com/ee/user/project/merge_requests/#checkout-locally-by-modifying-gitconfig-for-a-given-repository [2] https://stackoverflow.com/questions/53889035/bitbucket-server-api-get-raw-files-associated-with-pull-request
(In reply to Lars Vogel from comment #0) > Currently Egit provides a very strong EGit integration. I guess you meant Gerrit integration :-?
Regarding read-only references: My gut feeling says that a service specific number-to-URI translation is necessary in all cases, which does more than adding the number to a fixed URI prefix. I.e. we should rather ask github for the source URI of the PR instead of trying to use the read-only URI. The same has already been done for gerrit. Regarding github enterprise: I feel this feature would be worth implementing just for github.com alone, totally ignoring the enterprise version. Think of 80/20 rule.
I found this actually already works. * Create a Mylyn task repository of type Github/Pull Requests (requires mylyn-github connector installed, as described before). * Create Mylyn query for open PRs on a project you like. * Open a PR from the Mylyn Task list view. * In the upper right of the form based editor for the PR there is an icon "Fetch commits from PR", which will fetch into the matching git repo.
:-) So this just needs a bit polishing to make it more accessible. We could add a command similar to "Configure Gerrit" on the remote for the repository on Github and create the Mylyn PR query under the hood ?
Feature now available in IntelliJ https://www.jetbrains.com/idea/whatsnew/#v2019-1-version-control
More like https://www.jetbrains.com/idea/whatsnew/#v2018-3-version-control :)
The 4 or more points of comment 4 sound quite complicated. So I fully agree with Matthias needs to be simplified / more accessible by ""menu support" (see also bug 559856)
I'd like to see, without having to install Mylyn task, just an operation to checkout a random remote reference; ideally accessible from the Switch To submenus. Once we have such switch to, then it becomes only a matter of selecting the github repo and using the pulls/123/head reference (where 123 is PR name). Then, in another operation, we could imagine a switch to > Pull Request operation that would take care of opening a dialog to help getting the GitHub PR with just the PR number or URL (or later with some search key or whatever helps). All that could/should ideally work without Mylyn tasks.
On the push side a "Create a PR after this push" would be great. I frequently work in a branch, e.g., master and would like verify the change via Jenkins / build actions. So far I have to push to a new branch and switch to a browser to create a PR.
I see no activity here for a while now. It would be good to have people discuss and share their thoughts what the feature should look like.
(In reply to Thomas Wolf from comment #1) > 1. The refs/pull namespace is read-only, so you can't push new commits > onto a PR that way. IMO, we can start by just suppprting Ferch/Switch to ease reviews. Support for push can come later, especially since GitHib allow different strategies to update a PR (append or force push,os the initial PR mine or not...?) Are acceptable, it's tricky to giess user ezpextations for push. > 2. How to detect that a repo is a GitHub repo? IMO, alhtough it's incomplete, we could start by just supporting repositories from the guthub.com domain. That would be easy to start with and cover most of cases. (In reply to Jay Arthanareeswaran from comment #11) > I see no activity here for a while now. It would be good to have people > discuss and share their thoughts what the feature should look like. At this stage, I think we need more details to prioritize and drive actual dwcelopment work. Can you please elaborate which specific features you('d) need on a daily usage?
New Gerrit change created: https://git.eclipse.org/r/c/egit/egit/+/186090
New Gerrit change created: https://git.eclipse.org/r/c/egit/egit/+/186091
Here's a basic implementation that works exactly like the "Fetch From Gerrit..." wizard. That seems to cover the original request in comment 0. There's still room for future improvements; see the commit message of https://git.eclipse.org/r/c/egit/egit/+/186091 .
(In reply to Thomas Wolf from comment #15) > Here's a basic implementation that works exactly like the "Fetch From > Gerrit..." wizard. That seems to cover the original request in comment 0. That's really good!
New Gerrit change created: https://git.eclipse.org/r/c/egit/egit/+/186243
New Gerrit change created: https://git.eclipse.org/r/c/egit/egit/+/186340
@Thomas: do you think you could already merge your 1st patch so we could benefit from it by updating to a snapshot build already?
For alpha testing, you could also install EGit from the temporary update site produced by the Jenkins CI. Download https://ci.eclipse.org/egit/job/egit.gerrit/2420/artifact/org.eclipse.egit.repository/target/repository/ as ZIP and install from that archive. (Or expand the archive and install from the file system. I've had troubles with ZIP archives in the past.)
Gerrit change https://git.eclipse.org/r/c/egit/egit/+/186091 was merged to [master]. Commit: http://git.eclipse.org/c/egit/egit.git/commit/?id=efced836205c70cf917174092aee41e417fe1099
Gerrit change https://git.eclipse.org/r/c/egit/egit/+/186243 was merged to [master]. Commit: http://git.eclipse.org/c/egit/egit.git/commit/?id=ba427405c0aaa385da6ce381bc8709cf5bad77d4
Gerrit change https://git.eclipse.org/r/c/egit/egit/+/186090 was merged to [master]. Commit: http://git.eclipse.org/c/egit/egit.git/commit/?id=4602dc5242803be8ff02fa148a7fcc1984706d46
Gerrit change https://git.eclipse.org/r/c/egit/egit/+/186340 was merged to [master]. Commit: http://git.eclipse.org/c/egit/egit.git/commit/?id=6515840ee7ea9c36d78470b23b63a25779addc99
Preliminary N&N at [1]. [1] https://wiki.eclipse.org/EGit/New_and_Noteworthy/6.0#Fetching_Pull_Requests
I just installed the snapshot and am already happily extensively using it! Thanks!
Thanks, Thomas for fixing it. I opened Bug 576841 for an enhancement of the labels.
Thanks for taking care of this! Just noticed that it only works for github.com and not for github.abc.com. Is there a reason why this isn't working for me?
(In reply to Jay Arthanareeswaran from comment #28) > Thanks for taking care of this! > > Just noticed that it only works for github.com and not for github.abc.com. > Is there a reason why this isn't working for me? See the N&N for the upcoming EGit 6.0 for what to do[1]: define your own URL patterns. [1] https://wiki.eclipse.org/EGit/New_and_Noteworthy/6.0#Configuring_Hosts_for_Pull_Requests
(In reply to Thomas Wolf from comment #29) > See the N&N for the upcoming EGit 6.0 for what to do[1]: define your own URL > patterns. > > [1] > https://wiki.eclipse.org/EGit/New_and_Noteworthy/6. > 0#Configuring_Hosts_for_Pull_Requests And if you're wondering why it's different between Github and Gitlab: I am aware of at least two open-source projects using Gitlab and publishing at gitlab.abc.org: gitlab.eclipse.org and gitlab.gnome.org. So I included gitlab.<somedomain>.{com,org} by default. I'm not aware of any open-source project using github.abc.org, so I didn't include it. If someone runs Gitlab EE or Github Enterprise on other URLs, custom URL patterns can be defined.
(In reply to Thomas Wolf from comment #29) > See the N&N for the upcoming EGit 6.0 for what to do[1]: define your own URL > patterns. > > [1] > https://wiki.eclipse.org/EGit/New_and_Noteworthy/6.0#Configuring_Hosts_for_Pull_Requests > Awesome and thanks! Works like a charm.
The new feature works well. Thanks for the good work!
@Thomas: could you please check if there is a regression or just stupid user issue: https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/issues/24#issuecomment-1081745267
(In reply to Andrey Loskutov from comment #33) > @Thomas: could you please check if there is a regression or just stupid user > issue: > https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/ > issues/24#issuecomment-1081745267 Can't verify right now (will have to wait until tonight), but I'd be surprised if there was a regression. No changes in that area since the feature was introduced. Show your git config, please.
(In reply to Thomas Wolf from comment #34) > (In reply to Andrey Loskutov from comment #33) > > @Thomas: could you please check if there is a regression or just stupid user > > issue: > > https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/ > > issues/24#issuecomment-1081745267 > > Can't verify right now (will have to wait until tonight), but I'd be > surprised if there was a regression. No changes in that area since the > feature was introduced. Show your git config, please. See https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/issues/24#issuecomment-1081781005 The menu only shows up if the repo url ends with ".git".
@Andrey: it seems like a limitation in current implementation. I think this should be covered in a separate issue.
(In reply to Mickael Istria from comment #36) > @Andrey: it seems like a limitation in current implementation. I think this > should be covered in a separate issue. Yep, open a separate issue that this feature should also handle remote URIs not ending in .git. If you want to fix it yourself: most probably in GitHosts, line 55. Currently it requires \\.git, changing this to (?:\\.git) should resolve this. ("Probably" because I can't check right now myself; have no access to my EGit dev environment currently.) On projects in the package/project explorer, the menu item is, like "Fetch from Gerrit...", underneath Team->Remote.
(?:\\.git)? of course
(In reply to Thomas Wolf from comment #37) > (In reply to Mickael Istria from comment #36) > > @Andrey: it seems like a limitation in current implementation. I think this > > should be covered in a separate issue. > > Yep, open a separate issue that this feature should also handle remote URIs > not ending in .git. I've created bug 579477.
