Re: RFC: "negative" dirstat

[Linus Torvalds <torvalds@linux-foundation.org>]

On Mon, Apr 18, 2011 at 2:33 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> Are these removal really "remove old cruft, replace with a better version
> which does not have much common to removed stuff", or are they more like
> "remove N duplicated similar copies of old cruft, refactoring them
> properly and the result is used by N callsites"?

Right now, there not so much of either.

The _hope_ is that there will be "remove <n> different implementations
of some gpio driver, and replace them with a couple of generic ones
and some setup code".

So no, it wouldn't necessarily be about code movement at all, but
about totally different code.

> The second reason you gave in an earlier discussion why dirstat uses the
> damage assessor code was to disregard code movements.

No, that only works within a file, which sometimes is common when you
have to re-order functions because or some re-organization.

See for example commit 9d412a43c3b2 ("vfs: split off vfsmount-related
parts of vfs_kern_mount()") in the kernel for an example of why line
ordering shouldn't necessarily count against damage.

But what I'm talking about is really different code, not
re-organization of existing one.

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

Yes.

>                               Adding a lot of Documentation may be good,
> adding a lot of "subarchs that do not deserve to be" may be bad, and
> moving common logic from one existing subarch to a common file (which
> counts towards "literal-added" in that new common file, at the same time
> counting towards deletion, i.e. "size - copied", from the original) and
> reusing it in a new subarch by simply calling that common infrastructure
> is a very good thing.

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.

> 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. So I really don't
want to concentrate on the moving part. It's really about "some
operations actually clean up code and remove code in the process".

                  Linus