> On Dec 6, 2016, at 10:33 AM, Rainer Müller <rai...@macports.org> wrote: > >> On 2016-12-06 14:36, Mojca Miklavec wrote: >> >> When someone submits a pull request (let's assume that it's already >> perfect) and a committer fetches it, rebases it and commits it to the >> master, then the PR is not automatically linked to the commit (if >> rebasing happens in the meantime). Alternatives are: >> >> (a) press the rebase button on the website >> (b) force push to the branch of PR >> (c) ask the author to rebase >> (d) accept the fact that the two are not linked > > (e) add "Closes: #XYZ" to the commit message > >> Problems: >> >> (a) Committer's email is "random" rather than usern...@macports.org >> (b) The one submitting the PR has to allow this (not everyone is happy with >> it) >> (c) Timing. It's basically impossible to assure that even after the >> author rebases, some committer will pick it up and commit it fast >> enough (= before another commit flies in). >> (d) The obvious. PR will be marked as Closed (rejected?) rather than Merged. > > (e) avoids (a), does not require actions by the submitter as in (b)/(c). > The PR will still have a red "rejected" sign as in (d), but with a link > to the commit right next to it. > > This is therefore my preferred solution. For example: > https://github.com/macports/macports-ports/pull/61
I have generally come to prefer alternative B (rebase local PR branch against master, force-push PR branch, merge local PR branch into master, push master), but it admittedly requires more Git work and is relatively easy to screw up. vq
