<div dir="ltr">My 2 cents:<div><br></div><div>* cherry-pick will always change commit hash and github won't see it as the same commit as from original PR</div><div>* "Closed #10" syntax was designed to close Issues from commit messages. I think if you do "Closes #10" for PR it will close a PR in the way it will look like it was declined</div><div>* I think asking contributor to make required changes and then just merging is a proper way to manage PRs. If you want to help contributor add comments to bad lines or provide correct code snippets</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 3, 2016 at 11:46 AM, Lawrence Velázquez <span dir="ltr"><<a href="mailto:larryv@macports.org" target="_blank">larryv@macports.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On Nov 3, 2016, at 2:16 PM, Rainer Müller <<a href="mailto:raimue@macports.org">raimue@macports.org</a>> wrote:<br>
><br>
> On 2016-11-03 18:57, Lawrence Velázquez wrote:<br>
>>> On Nov 3, 2016, at 1:46 PM, Rainer Müller <<a href="mailto:raimue@macports.org">raimue@macports.org</a>> wrote:<br>
>>><br>
>>> I think the proper way to do it on GitHub would be as follows:<br>
>>> When the pull request author checked the box for "Allow modifications by<br>
>>> maintainers" [1], you can force-push your changes to the pull request<br>
>>> branch, replacing the original commits. Then you can merge the pull<br>
>>> request from the GitHub web interface.<br>
>><br>
>> GitHub will also automatically close the PR as "merged" if you push the<br>
>> PR branch's changes to master from a local client. It's quite nice.<br>
><br>
> If I understand this correctly, the exact commits have to be on the pull<br>
> request branch for GitHub to recognize you want to close the PR. So I<br>
> would have to push them first to the pull request branch and then to master.<br>
<br>
</span>Yeah, I think that's right. That means that rebasing from the command<br>
line is not feasible for most PRs because the contributors' branch is<br>
unlikely to be based on the absolute latest master. So I think the<br>
process you mentioned (push to collaborator's branch, rebase from the<br>
web) might become our standard operating procedure.<br>
<br>
vq<br>
<div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
macports-dev mailing list<br>
<a href="mailto:macports-dev@lists.macosforge.org">macports-dev@lists.macosforge.<wbr>org</a><br>
<a href="https://lists.macosforge.org/mailman/listinfo/macports-dev" rel="noreferrer" target="_blank">https://lists.macosforge.org/<wbr>mailman/listinfo/macports-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">With best regards, Ivan Larionov.</div>
</div>