Code longevity metrics give you clear visibility into several code quality problems that other metrics don't.
First, when code is removed or replaced within a few weeks, this means that it failed to meet requirements at best, and more likely suffered from severe bugs. The benefit of code longevity over traditional metrics like bug counts is it shows you which original change caused the problems so you can do a better job of preventing quality issues in the future.
Over a longer time frame, code longevity can highlight poor code quality by identifying code that had to be removed or refactored several months down the road vs. code that reached its full expected lifetime.
Finally, code longevity can pinpoint code that has been abandoned and is no longer maintained by identifying unusually low amounts of code replacement.
For every new commit, minware's code longevity tracing system looks at when each removed or replaced line of code was originally written using a method similar to Git blame. It then associates the removals with the original commit that added each line and aggregates them so that you can see how many code lines are still surviving at each point in the future.
minware's code longevity system does not actually look at the original code. Instead, it computes a hash of each line so that it can tell which lines are the same, but it does not store the code itself. However, minware's initial ingest step does temporarily read the original code to produce the hashes, though the code is not stored anywhere in minware's systems.
Yes, minware's code longevity tracing system will detect when a file has been renamed and treat it like it is part of a single file history the same way that Git blame is able to handle file renames.
Yes, unlike Git blame, minware's code longevity system will trace changes back to their original commits through squashes and rebases so that their longevity timeline doesn't end at the point of a squash or rebase.
(Nerd alert, this is a bit in the weeds.) The problem with Git blame and the reason we created our own system and submitted it for a patent is that Git blame uses a backward-looking algorithm that is unstable as you add new changes. That is, the Git blame for a commit B that comes right after commit A may be vastly different from commit A's blame as compared to the changes in commit B. This makes it unreliable for code longevity because code can disappear without actually being removed or come back after an earlier commit shows that it is gone.
minware's code longevity tracing algorithm maintains a mapping of when each line was written and incrementally updates that mapping with the same changes that are in each commit for guaranteed accuracy and stability of metrics over time (i.e., new commits will never affect past removals).