Re: RFC: "negative" dirstat

Linus Torvalds [off-list ref] writes:

On Mon, Apr 18, 2011 at 2:33 PM, Junio C Hamano [off-list ref] wrote:
...

quoted

I guess what it boils down to is what you are trying to measure as the
"goodness" value of a change.

Yes.

Yes. If I see a lot of lines added in Documentation/, I really don't
mind at all. And if I see a diffstat that says something like

   1057 lines added, 2901 lines deleted

I'm extremely happy. It's very different from one that would say

   2958 lines added, 0 lines deleted

even though --dirstat might consider the two equivalent right now.

I am afraid that this is ultimately "how to compare apples and oranges"
(or "which is juicier, oranges or squirrels?") question.

If you are willing to say

    1000 lines added, 700 lines deleted

means "It changes 700 lines (removing the original 700 and replacing them
with the new 700) and then adds 300 lines of new material", then you could
simply use the max(added, p->one->size - copied) instead of using the sum
of them as the damage count.  Of course, depending on the nature of the
change, the above interpretation does not apply in general.

quoted

At least, if you count literal-added vs src-copied across the files
within the subarch, instead of doing it per-file, you would be able to
detect the "moving" part more accurately.

Yes. However, "moving" is in many ways still not as interesting as
"actually removed".  Moving, on it's own, is a pretty neutral operation.

I think I was unclear, but I was shooting for the same thing.

I meant "by doing the added/copied computation across all files, the real
additions and deletions would reflect in the result without the noise from
the 'moving' part."