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

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.


_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Reply via email to