Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 576841

Summary: Pull request labels should be more descriptive
Product: [Technology] EGit Reporter: Lars Vogel <Lars.Vogel>
Component: UIAssignee: Project Inbox <egit.ui-inbox>
Status: CLOSED WONTFIX QA Contact:
Severity: normal    
Priority: P3 CC: Lars.Vogel, twolf
Version: unspecified   
Target Milestone: ---   
Hardware: PC   
OS: Windows 10   
Whiteboard:
Bug Depends on: 544815    
Bug Blocks:    

Description Lars Vogel CLA 2021-10-22 07:22:32 EDT 
Bug 544815 introduced support for PR integration which is great.

It would be nice to have a bit more information in the labels than only PR#. For example https://github.com/eclipse/windowbuilder/pull/73 shows up in WB as PR73 but it would be much more usable if the label / tooltip would show 

PR73  - Security manager removed from WB code 

so that the user does not have to check Github for the correct PR.
Comment 1 Thomas Wolf CLA 2021-10-22 07:31:12 EDT 
Not doable over the git protocol; the information is not provided before actually fetching.
Comment 2 Thomas Wolf CLA 2021-10-22 07:33:15 EDT 
(In reply to Thomas Wolf from comment #1)
> Not doable over the git protocol; the information is not provided before
> actually fetching.

... before actually _having fetched_ the commit. Also note that PRs can have their own messages, which may be unrelated to commit messages. Git doesn't know about those.
Comment 3 Lars Vogel CLA 2021-10-22 08:16:48 EDT 
Thanks, Thomas for the response. Should be mark this one as WONTFIX in this case?
Comment 4 Thomas Wolf CLA 2021-10-22 09:16:30 EDT 
Would need the REST API. That's the domain of the Mylyn Github connector; but Mylyn's fate is unclear.

I did look at using the REST API, too, when I did bug 544815. Using it would have some advantages, including being able to show PR messages and PR authors and so on. But using it is fraught with problems. Admittedly these could be overcome, but it'd be a lot of work:

* No general way to figure out the API URL from the git remote URI. There's no
  relation.
* The REST API may or may not be accessible with the same credentials as used
  for git fetch/push. If not, users need a way of maintaining separate
  credentials. It may or may not be subject to rate limits, which may or may not
  be a problem for our use case.
* There's (of course) quite some differences between the REST APIs of Github,
  Gitlab, Bitbucket Server, and Bitbucket Cloud. One would have to find the
  right abstractions first to abstract away these differences.
* Using the basic Github API from egit-github in core egit would introduce a
  nasty circularity between git repositories. At least the core egit-github
  library would have to be migrated to the egit main repo and be built there.
  But we don't really have time to improve it; it's basically in "just keep it
  working" maintenance mode since the original author (from Github) left.
* One risks re-implementing basically a whole lot already done in the Mylyn
  Github connector. Mylyn for instance has the whole machinery to manage
  different hosts with different credentials, with a fairly nice UI to boot.
Comment 5 Lars Vogel CLA 2021-10-27 08:18:41 EDT 
Do you know the branch for the pull request? In this case it would be really nice if the new local branch could be named similar to the branch for the PR.

Example:

Pull request from test-> master with PR number 12

Fetch Pull request -> Currently creates a new local branch with the name PR-12 and if you push this it creates a new branch.

Desired: create a new local branch with the name "test" so that any new changes will be pushed automatically to the remote branch "test".
Comment 6 Thomas Wolf CLA 2021-10-27 08:22:39 EDT 
(In reply to Lars Vogel from comment #5)
> Do you know the branch for the pull request?

No, we don't. The git protocol only gives us

  refs/pull/12/head -> SHA1 of commit

That's it.