Commit History vs User Convenience

[Mojca Miklavec]

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