I'm still trying to grok all this, despite having no earthly reason ever to do it ... I think I don't get how you use it as well as why. Will ask essentially the same question every time: how does this editing of the past help you accomplish this benefit listed?
The powerful growing observability and diffing logs debug technique is an excellent reason.
What can you observe and diff more easily this way than without.
Having strong proofs, that just keep getting stronger, that refactorings are indeed pure refactorings is an excellent reason.
How is it that the proofs get stronger? How is it different from putting the improved proofs at the tip of the spear? Are you building old versions just to run new tests on them?
The "keeping up with the herd of cats" to avoid Bing Bang integrations is an excellent reason.
How does this help?
Being able to drop the extended unit tests into the mainline to stop the herd of cats accidentally breaking things, even if the rest of the branch isn't ready, is an excellent reason.
How does this help? Wouldn't all your unit tests be available at the tip anyway?
Floods of microcommits of "obviously correct" tiny refactorings is an excellent reason.
How does this help do microcommits?
Using coverage analysis to see where you're starting to walk on shaky ground, and then retroactively? brace with unit tests _before_ all your changes is an excellent reason.
Again, are you running/testing old versions? If not, how is this different from adding tests wherever you are?
I'm clearly missing something ...
Ron Jeffries
Isn¡¯t testing?quality?in a lot?like weaving straw into?gold?
¡ª George Cameron
