Hi,
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.
Agreed. I mentioned this as an option on the git PR but on reflection,
given the size of the gcc rebuilds it is sub-optimal.
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.)
Agreed. My preference is 2. but I for sure would not object overly
strongly for 3 if others prefer this. I do agree its perhaps more
correct from the 'pure' git side, looking at the history, but has the
unfortunate side effect that users will see a revision being skipped.
(How many will notice is another question). So which is the worse evil ... ?
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.
To be honest, my concern with the above is to get adequate testing,
across a range of macOS versions, rather than nuances around the
revisions... So lets focus energies on that aspect...
Chris
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
