Hi! [ Not disputing that review is a substantial effort. ]
On Sun, 2025-08-17 at 22:33:16 -0400, Theodore Ts'o wrote: > You could just make the change yourself, and then do a "git commit > --amend", but then the MR won't get closed automatically, becaue the > forge won't recognize the modified commit. And if you do a "git > commit" instead ofa "git commit --amend", then you break bisectibility > of the git tree. > > Yes, you could then close the commit manually, but now it's more work > than the e-mail based workflow. I think in general forges have some logic to detect when you push the changes that are part of an MR/PR, but do not have the same commit id (either because you rebased them locally, or amended them, etc). For upstream projects where I've got MR/PRs enabled, I tend to automatically fetch them via a remote fetch configuration (like the one mentioned elsthread in Simon's reply), and then my usual workflow is to rebase and/or amend/fix/sign-off stuff, then push. But out of habit and to have a tracking reference (independently on whether I suspect the logic above might not trigger), I just add a pseudo-field in one of the commit messages like: Closes: !1000 Or «Fixes:» with a «#5000» or a full URL for issues, etc. Which can be configured then to auto-close the MR/PR/issue for you. (I think GitHub does this automatically, but GitLab only supports it for issues? :/) (I might then still want to comment on the auto-closed MR/PR to thank the contributor and explain the changes there explicitly, though, out of courtesy, but that's probably optional if that's covered in the commit messages with attribution or modification notes.) Thanks, Guillem
