PR final steps (to squash or not to squash)

Lawrence Velázquez larryv at macports.org
Mon Dec 12 01:21:39 CET 2016


> 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


More information about the macports-dev mailing list