PolyGerrit now supports cherry picking changes onto of other changes (as of 2.16.6 (not released yet)) (i did that change!). PolyGerrit is also gaining support for cherry picking changes even with merge conflicts (also done by me)! Also we are making CI comments pretty in PolyGerrit, see https://phabricator.wikimedia.org/F28291464%C2%A0(this work was done by thcipriani for blubber, which i have worked on to roll it out to all jobs (if you use the new UI)).
On Saturday, 9 February 2019, 03:08:34 GMT, Gergo Tisza gtisza@wikimedia.org wrote:
Here's a quickie: Alt-Shift+F (or Alt-F or whatever your browser uses for accesskeys) works in MediaWiki and Phabricator but not in Gerrit. On Fri, Feb 8, 2019 at 11:35 AM Daniel Kinzler dkinzler@wikimedia.org wrote:
* clicking on the name of a repo in a change should take me to a place where i can browse that repo. It currently takes me to a list of tasks on that project, which is quite useless. Same for the target branch.
You can click on the commit ID (in the new UI it's next to where you select the patchset version).If you want the gerrit admin page of the repo (which is fortunately a lot less often needed), you can switch back to old UI in the footer, and then click on the cog icon after the project name, instead of the project name itself. * git review: a nice shortcut for "rebase on change number nnnn". Same as the rebase button in gerrit, but allowing me to resolve conflicts locally.
check out the commit to rebase on (git review -d if you really want to rebase on another changese, although that's almost never needed), then git review -x nnnn-X instead of -x if it's going to be a cherry-pick. On Fri, Feb 8, 2019 at 1:07 PM Stas Malyshev smalyshev@wikimedia.org wrote:
One thing still missing for me is better ability to indicate which kind of attention the item needs from me.
Yeah, that view is not great. Besides review scores, it would be super nice to be able to see in the list view the number of unresolved comments by me and by the changeset owner. Couple of things for git review command too:
On that note (although I think that's a completely different universe, maintained by the OpenStack community, not the Gerrit one), two small annoyances I had with git-review:- When it generates the "multiple changes, Y/N" list, it compares HEAD with origin/master instead of the actual remote state of master. That can fail in a number of ways (shows already merged patches, sometimes shows all the changes which have been merged into core since I last did a git fetch), and performance-wise it is entirely pointless all the commands which trigger it involve heavy network traffic anyway.- When submitting multiple changes from a new repo, it sets up the commit hook for adding change IDs and adds a change ID to the last patch, but not the previous ones, so the submit will fail. One useful command for me would be "check out a change and put it in a branch named after topic of that change, overriding it if it existed". This allows easy syncing of patches where more than one person contributes to them.
Isn't that what git review -d does? The branch name is less useful, but usually the change id is at hand anyway.