On 06/10/16 12:15, Ryan Schmidt wrote:
On Oct 6, 2016, at 06:09, Chris Jones <jon...@hep.phy.cam.ac.uk> wrote:
On 06/10/16 11:43, Mojca Miklavec wrote:
On 6 October 2016 at 09:39, Chris Jones wrote:
How do I take the user's pull request, make additional changes, and commit
them to our master?
Anyone can commit to the branch created by the user for the pull request. So
you can just checkout that branch yourself, make changes, commit and push
them back to the branch, and thus the merge request.
Interesting, thank you, I didn't know (or think of) that.
My next question was going to be: what happens when user submits a
pull request that needs quite a bit of editing? Say that the user
first changes all the whitespacing together with content changes and
potentially does some other mistakes like increasing epoch for no good
reason etc. Of course he can then make another commit that changes
that back, but we would end up with super weird history for no good
reason unless we take the liberty to modify the commits (heavily)
before accepting them.
I guess one option would be to reject the request, providing information on
why, and leave it to the user to fix the issues and resubmit a new request. If
they need to they can rebase/revert their local checkout back to before their
changes, to remove the bad commits from the history.
I assumed that in such a case, where the contributor is (or we are) making several
commits to fix mistakes in a submission, we would use a "squash merge" (?) to
combine all the changes in the pull request into a single commit on master. The GitHub
web interface provides an option for this. If we want to rebase instead of merge (?) we
would need to write up a procedure for how that's accomplished.
yeah, that is probably better. Simpler for the user at least.
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
