Re: BUG? in --dirstat when rearranging lines in a file
- From
Johan Herland <johan@herland.net>
- Date
- Apr 8, 2011, 14:46 UTC
- Message-ID
- <201104081646.35750.johan@herland.net>
- In-Reply-To
- <BANLkTinEipewx2+Cx7Us0BSoSbjjU9uE6A@mail.gmail.com>
On Thursday 07 April 2011, Linus Torvalds wrote:
Show 14 quoted lines
> 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