Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes:
> On Mon, Apr 18, 2011 at 2:33 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> ...
>> 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.
>> 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."
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html