In my opinion: A single rev-bump is required when changes to the overall Portfile require it -- whether a single commit or multiple commits in a PR. The overall goal of a rev-bump is to force the port to be updated; it is a developer necessity & it's value is really not for the user's convenience.
I'd say so long as you note specifically in the commit message that a rev-bump -should- be done here but you're holding off for a future commit within the same PR, then that meets all of the basic requirements: it provides history & rationale, and still does the required rev-bump. To be fair: One could, of course, clone the MP GIT repo & check out the interim commit (without the rev-bump) ... but, I don't see why anyone would want to do this & if they are sophisticated enough to do this then they can figure out the rev-bump issue too. My US$0.02 worth ... - MLD On Mon, Oct 8, 2018, at 10:13 AM, 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. > 2) Create one pull request that increases the revision number only once > for the two unrelated changes. > 3) Create one pull request with several commits. Each commit increases > the revision number (for a total of two). > > 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. > 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. > > 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. > > Thanks, > Marcus
