Working with Git

[Davide Liessi]

2016-10-06 13:15 GMT+02:00 Ryan Schmidt <ryandesign at 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