These are chat archives for cherrypy/cherrypy

17th
Dec 2016
Sviatoslav Sydorenko
@webknjaz
Dec 17 2016 16:48
Wow
nice
I'm normally using my fork of a blueberrypy to generate and manage skeleton of cherrypy app
Sviatoslav Sydorenko
@webknjaz
Dec 17 2016 17:09
@jaraco a while ago GitHub has introduced this nice feature Squash and merge.
I suggest using it as a main method of doing merging and fallback to Rebase and merge if we need to preserve commits from feature branch.
This would make master branch history log much more nice to read :)
Do you mind?
Jason R. Coombs
@jaraco
Dec 17 2016 17:36
@webknjaz I’m more of the opinion that preserving history is important. Frequently, the thought process that led to the development of a feature, and thus the history of commits that resulted in the feature being merged, is just as important to the history as the changes themselves. Both ‘squash and merge’ and ‘rebase and merge’ are destructive to history, with the squash being the most destructive. I generally prefer a simple merge.
For example, in this last pull request #1531, if one had performed a squash and merge, it would have collapsed the separation of two unrelated changes into a single commit.
And if one desired to revert those changes, it would not be a simple matter of reverting a commit, but one would have to pick out the specific portion of the diff that were relevant.
Which is a manual and error-prone process.
So a squash and merge was inappropriate for this example.
There are others where I do see the value in a squash and merge or a rebase and merge, and I elect those on a case-by-case basis.
But unless I have reason to think that the squashed or rebased version is just as informative as the simple merge, I’ll prefer the simple merge.
The main reason I default to that option is it’s always possible to construct a squashed or rebased history based on the true history, but it’s difficult if not impossible to go the other direction.
Sviatoslav Sydorenko
@webknjaz
Dec 17 2016 18:54
Alright, I understand the point of having history relevant and support it. It's just I don't want to move a series of commits like Fix, Fix fix, Fix of a fix, Final fix into master making it look dirty. I think those have to be squashed into something relevant. Perhaps one doing the PR must reorder, rebase and squash their feature-branch on per-change basis (i.e. keeping only those commits that matter) by themself right before the merge to keep the history clean.
Jason R. Coombs
@jaraco
Dec 17 2016 19:05
The nice thing about a merge commit is you can rely on that commit itself to represent the effective change. All you have to do is shield your eyes from the dirty details in the feature branch and focus on the merge commit. SCM tools and sites like Github make this review trivially easy. Consider e92fc1b5d8499 - that appears in Github as a squashed diff. Also in SourceTree. But if all you want to review is the fix for #1530, you can look at 76c1dc87235, which is the commit linked in the ticket.
I do agree, if users want to curate their commits, they’re welcome to do so to improve the longevity of their contribution.