On Sun, Aug 17, 2025 at 10:22:57PM +0100, Richard Lewis wrote: > Peter Pentchev <roam@ringlet.net> writes: > > > 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 think you would just use git merge and git push etc from a command > line like any other branch. (i assume deleting the merge-request branch > from the command-line would close the MR, but maybe you need to use some > salsa api instead) But that would mean that you do not really mark the merge request as, well, merged. This might be okay with some contributors; with others it might leave a bit of a sour taste. As with so many other things, it depends. 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