Commit History vs User Convenience

[Chris Jones]

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
>