PR final steps (to squash or not to squash)

[Lawrence Velázquez]

> On Dec 5, 2016, at 7:37 AM, René J.V. Bertin <rjvbertin at gmail.com> wrote:
> 
> I guess we all have better things to do than this kind of task.

Our commit history is essentially communication with future committers
about what we did and why. Like any other communication, it should be
clear and useful.

Much like writing documentation, polishing the commit history is not
pleasant in the moment but is nevertheless time well-spent.

> I can see some justification for it in (very) complex software where
> you may be patching multiple files at once, but Portfiles are by
> definition single-file programs that are rarely of true complexity
> (rather, much complexity is hidden in "base").

They are also correspondingly easier to revise.

> OTOH it *is* true that whitespace changes can have more side-effects
> in Tcl than they have in C, but that's also a possible source of error
> when a 3rd party starts splitting up more elaborate change sets.

If you are worried about someone else editing your changes and botching
them, I encourage you to make them presentable yourself. Failing that,
committers reserve the right to modify submissions as they see fit
before merging.

> Even if one can still describe the evolution in a chronological
> sequence of things one has changed it can be really untrivial to start
> over and recreate the corresponding patches (which one would have to
> test, which means introducing local regressions, etc).

It doesn't have to be chronological, and each step need not be "correct"
on its own. We expect users to always have the latest ports tree, so
it's only important that the final result be correct. For example, in
a sequence of commits that each changes a port's installed files, only
the final commit need actually perform a revbump.

vq