Hi, Below is my opinion.
On Mon, 8 Oct 2018 at 16:13, Marcus Calhoun-Lopez wrote: > > I was hoping to get some help with how best to balance commit history and > user convenience. > > I would like to make two unrelated changed to the GCC ports. > Each change requires a revision increase of all the GCC ports. > > There seem to be a few options: > 1) Create two separate pull requests and have them merged separately. This makes absolutely no sense unless one change is straightforward and urgent (and could be merged quickly), and the other change is controversial & requires a lot of time to reach the consensus. Or some other "similar" scenario. Merging the first commit will necessarily introduce more work needed to fix the second commit before being able to merge that one. > 2) Create one pull request that increases the revision number only once for > the two unrelated changes. That's OK. > 3) Create one pull request with several commits. Each commit increases the > revision number (for a total of two). That's also OK. > Personally, I believe option 3 is the best choice. > The history remains clean, and nobody has to rebuild GCC twice in a matter of > a few days. That is true for both 2 and 3. I would probably go for 2, but would not object number 3 which is theoretically "more correct". The basic idea is that you want to avoid having to rebuild the ports N times (either on the buildbot or for the user compiling manually). By implementing number 3 you cater also those users who would happen to use git and do some bisection on port history and end up precisely between the two of your commits. That's a set with the expected number of elements around 0. (We could have run a job on the buildbot after each individual commit, but we consciously avoid that since it doesn't really bring any added value. It would make a difference then. It doesn't make a difference now.) Note that we sin in a similar way all the time by fixing a port in one commit and revbumping dependencies in the next commit(s). By doing this we are also creating an inconsistent state (not to even mention times when we in fact forget to revbump dependent ports altogether). > I have created such a pull request > (https://github.com/macports/macports-ports/pull/2730). > > However, the comments in the PR seem to indicate that option 2 or 3 is > preferable. Loosing any energy fighting for option 2 vs. 3 makes absolutely no sense. Both are fine. Option 1 is not forbidden, only highly suboptimal in most cases. > I was hoping to see if others had any strong feelings about this. > Ultimately, it makes little difference to me, but we have had concerns in the > past about frequent rebuilds of large ports such as GCC. True, we should try to avoid rebuilds. But rebuild would only arise from option 1. Mojca