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,
(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(a)wikimedia.org>
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(a)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
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.