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 ‘orphan’ 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 email@example.com for 24/7 assistance.