On Sun, Aug 17, 2025 at 11:46:29PM +0300, Peter Pentchev wrote: > On Sun, Aug 17, 2025 at 09:34:14PM +0100, Richard Lewis wrote: > > "Theodore Ts'o" <tytso@mit.edu> writes: > > > > > In some cases, if it's a patch sent via e-mail, I'll just fix up the > > > patch and then let the contributor know that they failed to do error > > > checking, or their patch had a buffer overrun and result in a security > > > vulnerability etc. But with a merge request, all I can do is explain > > > what they did wrong, and ask them to resubmit the merge request. > > > > Not looking to argue the main point (90% of everything is crud, and i > > dont think anyone things every contribution must be accepted), but this > > statement confused me: the merge request is already in git, so i dont > > understand why people think it is harder to use than a patch attached to > > an email? you can check out a merge request and amend or cherry pick > > commits. you could even run git diff and pipe the result into a patch > > and use whatever existing workflow works for the bts? > > ...but how do you then tell the Git forge to use your changes when > you want to tell it to merge this merge request? I mean, yes, if the merge request has been made from a different branch in the same Git repository, so you actually have enough access to force-push your changes to that branch, that might even be possible, but first, that's not always the case, and second, even then that is not always easy and convenient. G'luck, Peter -- Peter Pentchev roam@ringlet.net roam@debian.org peter@morpheusly.com PGP key: https://www.ringlet.net/roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
Attachment:
signature.asc
Description: PGP signature