2016-10-06 13:15 GMT+02:00 Ryan Schmidt <ryandes...@macports.org>: > 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.
May I suggest instead that we avoid squashing *all* changes of a pull request in a *single* commit? Of course, if there are many commits that address a single bug, I think it is good to squash them into one single commit. What I would oppose is having a single commit that upgrades the version, restructures the Portfile and addresses bugs, all at the same time, unless the changes really are entangled. In case of complicated history of commits in a pull request (because it was complicated already in the beginning, or as a result of pull request revision), I think that the contributor should fix the history of the branch in order to get one logical change per commit (usually it is just a matter of reordering and squashing commits using the interactive rebase, i.e., `git rebase -i`). Another way would be to require contributors to address only one issue (be it upgrading, fixing a single bug, ...) per pull request: in that case I would have no objections to squashing the whole pull request in a single commit. One way or the other, I think the "one logical change per commit" rule of thumb is very important in order to really have a useful and tidy history. Best wishes. Davide _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
