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 (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
<[email protected]> 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 <[email protected]> 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 <[email protected]> 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.
_______________________________________________
Wikitech-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
