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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxx>
www.herland.net
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]