Re: BUG? in --dirstat when rearranging lines in a file

[Johan Herland <johan@herland.net>]

On Thursday 07 April 2011, Linus Torvalds wrote:
> On Thu, Apr 7, 2011 at 6:49 AM, Johan Herland wrote:
> > Consider the following sequence of commands:
> > [...]
> > $ git diff --stat
> >  dir/file |    2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> > $ git diff --dirstat
> > $ # WTF!?
>
> So the "--dirstat" thing really is different - it has never done a
> full patch, it really only does a line hash count and then estimates
> the amount of deleted/new code from that.
>
> [...]

Ok, so here are 3 patches to somewhat improve the situation without 
making --dirstat too ugly or expensive.

#1: Simply document the current behavior.

#2: Improve --dirstat-by-file. It doesn't really care about the per-file 
analysis done by --dirstat, but only whether or not a file has changed 
at all. Since the diff queue does not contain unchanged files (<- this 
is an assumption that I hope someone with more diffcore knowledge can 
verify), we can unconditionally assign damage == 1 to each entry in the 
diff queue, and bypass the entire --dirstat per-file analysis.

#3. This is a quick/ugly hack that depends on the same assumption as #2: 
If an entry is in the diff queue, we now that it is not unchanged. So 
if the per-file analysis yields damage == 0, we know that it must have 
overlooked something (rearranged lines), so we set damage = 1 instead. 
The logic is that underrepresenting a change in --dirstat is better 
than ignoring it...


...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net