Bugzilla – Full Text Bug Listing
| Summary: | Provide UI to fetch change from Gerrit | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Michael Rennie <Michael_Rennie> |
| Component: | Git | Assignee: | Grant Gayed <grant_gayed> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | antonm, curtis.windatt.public, john.arthorne, ken_walker, maciej.bendkowski, mamacdon, matthias.sohn, michael.ochmann, Szymon.Brandys |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 425233 | ||
|
Description
Michael Rennie
If you 'fetch' the remote, the commit should be available. We have in the Git Repo page a way to open a commit (Cmd-Shift-H on Mac). So some of this is already in place but the workflow is not great. I've never seen a full walkthrough of someone doing this on Eclipse so that would be a start for me to understand how committers there do it. http://wiki.eclipse.org/Platform-releng/Git_Workflows#Gerrit_workflow_for_a_committer Describes the Eclipse workflow we use, most of which can work on Orion now http://wiki.eclipse.org/EGit/User_Guide#Fetching_a_change_from_a_Gerrit_Code_Review_Server Describes how to use eGit to checkout a gerrit change. Basic is open pull from gerrit from the context menu, enter the change number, ctrl-space to get the full id (change number + patch number). It will create a new local branch with the change, you can amend the commit to push a new patch set to the gerrit change or cherry pick it onto master. In my opinion, we should integrate the Gerrit workflow into our 'Ask for review' mechanism. Also, having a 'Getting started' section for contribution via Gerrit would be neat. (In reply to Maciej Bendkowski from comment #3) > In my opinion, we should integrate the Gerrit workflow into our 'Ask for > review' mechanism. Also, having a 'Getting started' section for contribution > via Gerrit would be neat. "Ask for Review" was added in pre-Gerrit time. Our Orion mechanism used mostly for GitHub contributions has its own UI, and Gerrit has its own. Could you elaborate how you would like to integrate it? (In reply to Ken Walker from comment #1) > If you 'fetch' the remote, the commit should be available. We have in the > Git Repo page a way to open a commit (Cmd-Shift-H on Mac). So some of this > is already in place but the workflow is not great. > > I've never seen a full walkthrough of someone doing this on Eclipse so that > would be a start for me to understand how committers there do it. If we are talking about only Fetch, everything is in place IMO. But it may be tricky to update changes in Gerrit. For instance EGit adds Change-Id to commit comment. I think we can make some small tweaks that will help Gerrit users. This bug is about adding the ability to fetch from gerrit, but I just ran into problems trying to push to gerrit. I committed locally with the signedoffby and changeid properties, pushed to the gerrit remote. Progress said waiting for remote 'gerrit' and it waited forever, no response, the change never showed up on gerrit. I ended up just using eGit again. It could be a problem with my configuration, but it matches up with what I have set up in Eclipse. (In reply to Curtis Windatt from comment #6) > This bug is about adding the ability to fetch from gerrit, but I just ran > into problems trying to push to gerrit. I committed locally with the > signedoffby and changeid properties, pushed to the gerrit remote. Progress > said waiting for remote 'gerrit' and it waited forever, no response, the > change never showed up on gerrit. > > I ended up just using eGit again. It could be a problem with my > configuration, but it matches up with what I have set up in Eclipse. You probably don't display messages sent by the server which you can retrieve from PushResult's base class OperationResult.getMessages(). JGit's class ChangeIdUtil provides the logic to generate a changeid when creating a new commit. (In reply to Szymon Brandys from comment #5) > (In reply to Ken Walker from comment #1) > > If you 'fetch' the remote, the commit should be available. We have in the > > Git Repo page a way to open a commit (Cmd-Shift-H on Mac). So some of this > > is already in place but the workflow is not great. > > > > I've never seen a full walkthrough of someone doing this on Eclipse so that > > would be a start for me to understand how committers there do it. > > If we are talking about only Fetch, everything is in place IMO. But it may > be tricky to update changes in Gerrit. For instance EGit adds Change-Id to > commit comment. I think we can make some small tweaks that will help Gerrit > users. In EGit we have a wizard to configure a remote for Gerrit, it sets the git configuration option gerrit.createchangeid to true which signals to the commit dialog and staging view that a changeid should be inserted automatically. In addition the wizard asks the user for which branch he wants to push changes for review. It also changes the default fetch refspec to also fetch review summary notes which provide an audit trail for finished reviews so that they are also available as git notes in your clone. Recently we added another little dialog to allow pushing a change for review for a different branch than the one being configured in the push refspec. This is useful for maintenance branches which are used less frequently than master. (In reply to Curtis Windatt from comment #6) > This bug is about adding the ability to fetch from gerrit, but I just ran > into problems trying to push to gerrit. I committed locally with the > signedoffby and changeid properties, pushed to the gerrit remote. Progress > said waiting for remote 'gerrit' and it waited forever, no response, the > change never showed up on gerrit. > > I ended up just using eGit again. It could be a problem with my > configuration, but it matches up with what I have set up in Eclipse. I seems that the push command in the backend ignores the configured push ref spec, but always pushes to refs/heads/<branch>. See /bugs/show_bug.cgi?id=424313. In regards to fetch, what if we provided a new git section, similar to the git log page that listed all of the refs/changes/* available? I imagine we could get additional information from the last commit. Something to consider over following exactly what eGit does (content assist to fill in the change id). (In reply to Matthias Sohn from comment #8) > In EGit we have a wizard to configure a remote for Gerrit, it sets the git > configuration option gerrit.createchangeid to true which signals to the > commit dialog and staging view that a changeid should be inserted > automatically. Although such a wizard would be desirable to simplify the Gerrit confguration, I think we could start with just a "ChangeId" checkbox next to the "Amend" in the commit dialog --- very similiar to the egit commit dialog. I created a couple of patches as demonstration: Server: https://git.eclipse.org/r/#/c/19985/ Client: https://git.eclipse.org/r/#/c/19986/ The idea is to enhance the commit REST request by an optional boolean flag "ChangeId" that, if set, triggers jgit to add a change id on the fly. The changes to the UI are rather trivial and just a copy of the Amend mechanism. Hey Matthias, is this something you want to take ownership of? (In reply to Curtis Windatt from comment #10) > In regards to fetch, what if we provided a new git section, similar to the > git log page that listed all of the refs/changes/* available? I imagine we > could get additional information from the last commit. > > Something to consider over following exactly what eGit does (content assist > to fill in the change id). Depending on the repository you are looking at there could be a huge number of refs/changes/* (we have a repository with > 100k) so listing all of them probably doesn't make much sense. That's why egit asks the user to provide the change number. We may consider to use the Gerrit REST API to use a query to find the changes the user is interested in but depending on the Gerrit server's configuration this may require another set of logon credentials. If we go this path the first question would be which changes the user might be interested in. Those pending in review are often interesting. But sometimes you want to download a patchset of an already submitted or abandoned change. In this case we need to ask the user. (In reply to Matthias Sohn from comment #13) ... > We may consider to use the Gerrit REST API to use a query to find the > changes the user is interested in but depending on the Gerrit server's > configuration this may require another set of logon credentials. If we go > this path the first question would be which changes the user might be > interested in. Those pending in review are often interesting. But sometimes > you want to download a patchset of an already submitted or abandoned change. > In this case we need to ask the user. here the Gerrit REST API for Gerrit 2.7 (it's still growing) https://gerrit-documentation.storage.googleapis.com/Documentation/2.7/rest-api-changes.html and 2.8 https://gerrit-documentation.storage.googleapis.com/Documentation/2.8/rest-api-changes.html (In reply to Michael Ochmann from comment #11) > (In reply to Matthias Sohn from comment #8) > > In EGit we have a wizard to configure a remote for Gerrit, it sets the git > > configuration option gerrit.createchangeid to true which signals to the > > commit dialog and staging view that a changeid should be inserted > > automatically. > > Although such a wizard would be desirable to simplify the Gerrit > confguration, I think we could start with just a "ChangeId" checkbox next to > the "Amend" in the commit dialog --- very similiar to the egit commit dialog. > > I created a couple of patches as demonstration: > > Server: https://git.eclipse.org/r/#/c/19985/ > Client: https://git.eclipse.org/r/#/c/19986/ > > The idea is to enhance the commit REST request by an optional boolean flag > "ChangeId" that, if set, triggers jgit to add a change id on the fly. The > changes to the UI are rather trivial and just a copy of the Amend mechanism. moved this enhancement to a separate bug 425272 (In reply to Ken Walker from comment #12) > Hey Matthias, is this something you want to take ownership of? yes, I want to take ownership as we need Gerrit support in Orion for our use of Orion. I filed a number of enhancement bugs to capture my current view on what is missing for a decent Gerrit support, see https://bugs.eclipse.org/bugs/showdependencytree.cgi?id=425233&hide_resolved=1 I feel ready on the server side but need some guidance for client side enhancements since so far I didn't do any changes in the Orion client yet. Anything I can read to learn how to develop Orion client enhancements ? What UI guidelines should we follow besides looking at the existing UI, is that documented somewhere ? We will use Gerrit to review the changes needed to implement Gerrit support in Orion, it would be nice if some of the Orion experts could participate in reviewing our work especially on the client side. That's probably the fastest way to get us on speed. Does the project do UI reviews before/after bigger enhancements are implemented ? (In reply to Matthias Sohn from comment #16) > yes, I want to take ownership as we need Gerrit support in Orion for our use > of Orion. Assigned to you, Matthias. > What UI guidelines should we follow besides looking at the existing UI, is > that documented somewhere ? We will use Gerrit to review the changes needed > to implement Gerrit support in Orion, it would be nice if some of the Orion > experts could participate in reviewing our work especially on the client > side. That's probably the fastest way to get us on speed. We have a design repository, where some of our ongoing ideas are being documented (ssh://git.eclipse.org/gitroot/orion/org.eclipse.orion.design.git). Anton McConville is our main UI/UX designer right now. Adding him on CC. We need to address the Gerrit fetch work-flows on our git repository views. Matthias, are you still interested in taking over this bug? (In reply to Maciej Bendkowski from comment #18) > We need to address the Gerrit fetch work-flows on our git repository views. > Matthias, are you still interested in taking over this bug? not in the next few months as I am busy with other stuff at the moment Closing as part of a mass clean up of inactive bugs. Please reopen if this problem still occurs or is relevant to you. For more details see: https://dev.eclipse.org/mhonarc/lists/orion-dev/msg04002.html |