pando.py
pando.py copied to clipboard
AspenWeb
automate the changelog
We started talking on #529 about automating the changelog more. We're going to try squash-and-rebase to land PRs (we should write a doc about that) as a way to keep cleaner history on master that can be more useful as or for a changelog.
-1 on squashing history. An automatic changelog would be nice, but it's not important enough to destroy history, especially when there are cleaner solutions like adding custom Changelog: lines in commit messages.
destroy history
GitHub keeps old history around, so it's not actually destroyed. If you mention the previous HEAD commit after rebasing (here's an example), then it's pretty easy to get back to if need be.
When I'm looking into the history of a specific line or file I don't do it on GitHub, I do it locally with a git UI that makes it easier to browse the history. Also, relying on GitHub is not a long-term solution.
Okay, fair enough. Another option then would be tag the HEAD before squashing.
A tag would indeed protect the commits, they still wouldn't show up in the history though, so a git blame will lead you to a big squashed commit instead of the actual commit that introduced the change.
I haven't watched the call with @pjz because it's a bit long, is there some reasoning in it that hasn't been exposed in this issue?
@Changaco Nothing super-definite, no. I introduced the idea of tying the notice of the Python (etc.) versions that we support to specific Aspen versions, via the changelog. That led us into talking about automating the changelog, which is how we ended up here. Honestly not a huge priority for me, I'm happy not to push it (by squashing the commits on #527, e.g.), until we've worked it through here.
@Changaco yes, git blame will (correctly) lead you to the 'big squashed commit'... instead of incorrectly leading to some random unfinished-small-intermediate commit. As for big commits... we could make an effort to not have really huge changes all in one PR.
As for big commits... we could make an effort to not have really huge changes all in one PR.
Too late for that on #527 (was it possible?).
@pjz Intermediate commits can be squashed into a smaller number of "complete" commits. I usually do that kind of rebasing before pushing, but it can also be done later and force-pushed.
Wanting to squash all PRs into single commits is assuming that the right number of "complete" commits in a PR is always 1. I disagree with that assumption. Sometimes big commits are inevitable, especially when doing big refactorings, but most of the time I think it's better to split the changes into multiple "complete" commits.