Working with Git

[Ryan Schmidt]

> On Oct 6, 2016, at 7:15 AM, Davide Liessi <davide.liessi at gmail.com> wrote:
> 
> 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.

Yes. My point is that we often get contributions in Trac that are wrong in some way. The user wants to upgrade the version, and they forget to remove the revision line. Or the project has moved to github, but they've manually changed master_sites, homepage, distname, livecheck, etc. in the portfile instead of using the github portgroup. I don't want a series of commits on master that reflect the history of correcting those mistakes--mistakes which originated with that pull request. We currently don't have that in Subversion because we fix those problems before committing.

If there are easy ways to rewrite the history of a pull request, by all means, let's suggest the user do that, and provide instructions for how to do so. I have no idea how to do it.