Hi Lucas,
Thanks a lot for the update. I just tried this on
and
I confirm that it's working. :)
*--*
*</Derick <https://www.mediawiki.org/wiki/User:X-Savitar>>*
On Tue, Apr 30, 2019 at 2:06 PM Lucas Werkmeister <
lucas.werkmeister(a)wikimedia.de> wrote:
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 <
kharlan(a)wikimedia.org>gt;:
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(a)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 <
> gtisza(a)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(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 <smalyshev(a)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(a)lists.wikimedia.org
> >
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l