FYI, the improvement suggested in this thread back in January – I wonder if it would be possible to allow comments with “recheck” commands? >
+1 to Lucas' proposal, it should be possible to blame Jenkins within recheck > comments. > – has now been implemented. You can add additional comments after the word “recheck”, as long as “recheck” is the beginning of the comment and a word on its own (e. g. “rechecking because of…” will not work, and neither will “you need to wait until Txxxxxx is done and then recheck”). Working examples would be: recheck, T222131 was fixed > recheck to see if this happens consistently or not > recheck, SomeOtherExtension was broken and has been fixed in the meantime > Cheers, Lucas Am Mi., 27. Feb. 2019 um 19:34 Uhr schrieb Kosta Harlan < khar...@wikimedia.org>: > It would be nice to be able to add screenshots / images in comments. As it > is, I put a screenshot in phab and link to that from Gerrit, but it’s > cumbersome. > > Kosta > > > On Feb 26, 2019, at 7:25 PM, Paladox via Wikitech-l < > wikitech-l@lists.wikimedia.org> wrote: > > > > 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 < > gti...@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 <dkinz...@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 <smalys...@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. > > _______________________________________________ > > Wikitech-l mailing list > > Wikitech-l@lists.wikimedia.org > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > > _______________________________________________ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Lucas Werkmeister Full Stack Developer Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin Phone: +49 (0)30 219 158 26-0 https://wikimedia.de Imagine a world in which every single human being can freely share in the sum of all knowledge. Help us to achieve our vision! https://spenden.wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/029/42207. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
