On 2019-04-09 07:43, Isarra Yos wrote: Hopefully this will not stay disabled forever, for I also miss the feature. In the meantime, you can use the traditional Git way of generating patch files and sending them by email (or perhaps, in a modern twist, via Phabricator). To generate a patch file of the most recent commit: git format-patch -1 (that's 'dash one', and it's critical, because otherwise Git will generate patch files for ALL commits) Then upload the generated file to Phabricator or something. To apply such a patch file and turn it into a commit: git am foo.patch There are some other options for dealing with multiple dependent commits, if you ever need them. -- Bartosz Dziewoński

On 09/04/2019 09:21, Bartosz Dziewoński wrote: The problem is I'm going to need to do that for like one in every five commits, and often for multiple patches in a set. And... yes, we /do/ wind up with multiple dependent commits at times. To explain why this comes up so much for me: I am a UX designer. I'm not much of a dev. Most of what I do is describe generally what I want and then throw it at someone else, and they implement the actual logic, but then they pass it back to me to fill in the rest of the interaction stuff, because not only would it be incredibly tedious for me to try to explain every possible combination users might run into, it probably wouldn't even work. Without the code in front of me, without testing it and playing through each use case to ensure it actually results in the expected behaviour, I am going to miss things. While it does work in some cases to simply have the logic in one patch and the interaction in another, much of what we work on is considered stable, where we should not be merging half-complete patches unless we absolutely must. (Note too that this is specifically /my/ use case - this isn't even getting into issues with minor changes that are easier to apply than to explain, especially when helping newcomers through where it'd be needlessly frustrating for them to implement a bunch of minor fixes when the core of their patch is in fact good; or when just dealing with typos; or when restoring someone's five-year-old abandoned patch because wait, we actually do need that now; or...) Should we just, uh, not be using gerrit, or something? Because that's just... complicated. -I

On 09/04/2019 17:38, Isarra Yos wrote: To clarify, I get what you're trying to do, but there has got to be a better solution besides denying key features to and thus impairing long-term contributors, because disabling this for everyone (but apparently WMDE (?!)) does exactly that. On the wikis, for instance, we have specific groups for this sort of thing (rollback, file moving, bypass captcha, bypass rate limits), to let established users do the things they need to do, without it being allowed of absolutely everyone from the start, and without requiring them to be admins, either, to do it. Perhaps actually using one of our more general existing groups for this here would make sense? -I

On 09/04/2019 19:40, Tyler Cipriani wrote: Thank you. And apparently I was only even added to that group just last night in the hopes that it would get around this, so... now that it does, great! (For anyone else who needs to be added to this for now, who should they be reaching out to?) Sorry about reacting so unkindly - it was just particularly frustrating when it seemed like I was being ignored here, but other groups were being resolved (though as I understand it now, apparently specific members with access simply added that themselves, go figure). -I

On 09/04/2019 17:53, Greg Grossmeier wrote: Most of MediaWiki's anti-abuse features consist of only applying certain rights to certain groups. This is, likewise, a certain right. Gerrit, likewise, has groups. This right can be attached to groups, as evidenced by the fact that it has already been attached to certain groups. Given that we have no other feasible ways to do the thing the right allows, all I am asking is that this right be added to something that known volunteers and other trusted contributors can be added to. I believe there is even a group called 'trusted-contributors' already. -I