PR final steps (to squash or not to squash)

[Lawrence Velázquez]

> On Dec 6, 2016, at 10:33 AM, Rainer Müller <raimue at 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 username at 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