In this article, we'll go over how squashing commits affects your Flow data and why you cannot view presquashed commits.
Does squashing commits change the stats in Flow?
Yes, you'll see some change in the reports when squashing.
From Git's perspective, squashing is a form of historical ‘revisionism’ and alters the Git record. Right now, we've taken the approach of staying true to the Git history, and so you'll see some change in the reports when this is changed.
Squashing is the process of bundling multiple commits into a single commit. This can be used to combine less important commits into a single commit to make the commit history easier to understand. Since a lot of development happens incrementally, not all of the commits in your history will be valuable to have in the final code. For more context, here's a blog post about what really happens when you squash commits.
Actual changes in stats will vary a bit depending on what’s being squashed.
Here's a great math analogy to illustrate how squashing will end up affecting the rolled-up statistics:
Suppose you have this math expression:
2 + 3 - 4 + 6 - 8 + 3 = 2
Squashing this thing would be like placing parentheses somewhere in the middle:
2 + 3 - (4 + 6 - 8) + 3 = 6 2 + (3 - 4 + 6 - 8) + 3 = 2 2 + 3 - (4 + 6) - 8 + 3 = -10
What’s curious is that as long as you're only squashing additive parts, it's still possible to sometimes get the same results as before squashing:
(2 + 3) - 4 + 6 - 8 + 3 = 2
So the effect on stats will depend a bit on the exact changes you're squashing.
Want to know how squashed commits appear in the Work log report? Here is how Flow handles squashed commits.
Can I see my pre-squashed commits?
After a fair amount of exploring, we haven't yet settled on how the right way to handle that would be.
Consider the following scenario where commits A, B, C, D, and E are made on a feature branch early in the week, and then Squashed in Commit F on Friday :
What you'll see in Flow is just commit F and not the others.
Flow visualizations use Git as the record of authority and we display the revised history post-Squash. In the Work log report we filter by unique SHA. Even though commit F is on the feature and master branch, the commit will only appear once in this report alongside the gray merge commit.
How we got here
We've arrived at this solution so far, because of concerns that inconsistency might lead to misunderstandings.
The challenge is primarily on the data side. Because nobody really stores this information over the long term, the commits post-Squash get trashed eventually.
If we store it ourselves, this leads to some issues with how we might present it:
- Historical data would always be incomplete—and inconsistent with contemporary data
- There can be a near-infinite amount of 'true' histories, depending on how branching, Squashing, and Rebasing happens. It's not clear which one we should present by default
This is definitely something we’re tracking. If you have suggestions on how this should work, we'd love to hear from you.
You may see it in the future as an optional mode to certain reports, though this will almost certainly have to bake in the notion of 'perspective' to address (2) above, which adds complexity to the implementation.
Not really sure about squashing? Here is what really happens when you squash commits.
If you need help, please email firstname.lastname@example.org for 24/7 assistance.