1. 13 2月, 2008 1 次提交
    • L
      Add "--dirstat" for some directory statistics · 7df7c019
      Linus Torvalds 提交于
      This adds a new form of overview diffstat output, doing something that I
      have occasionally ended up doing manually (and badly, because it's
      actually pretty nasty to do), and that I think is very useful for an
      project like the kernel that has a fairly deep and well-separated
      directory structure with semantic meaning.
      
      What I mean by that is that it's often interesting to see exactly which
      sub-directories are impacted by a patch, and to what degree - even if you
      don't perhaps care so much about the individual files themselves.
      
      What makes the concept more interesting is that the "impact" is often
      hierarchical: in the kernel, for example, something could either have a
      very localized impact to "fs/ext3/" and then it's interesting to see that
      such a patch changes mostly that subdirectory, but you could have another
      patch that changes some generic VFS-layer issue which affects _many_
      subdirectories that are all under "fs/", but none - or perhaps just a
      couple of them - of the individual filesystems are interesting in
      themselves.
      
      So what commonly happens is that you may have big changes in a specific
      sub-subdirectory, but still also significant separate changes to the
      subdirectory leading up to that - maybe you have significant VFS-level
      changes, but *also* changes under that VFS layer in the NFS-specific
      directories, for example. In that case, you do want the low-level parts
      that are significant to show up, but then the insignificant ones should
      show up as under the more generic top-level directory.
      
      This patch shows all of that with "--dirstat". The output can be either
      something simple like
      
              commit 81772fe...
              Author: Thomas Gleixner <tglx@linutronix.de>
              Date:   Sun Feb 10 23:57:36 2008 +0100
      
                  x86: remove over noisy debug printk
      
                  pageattr-test.c contains a noisy debug printk that people reported.
                  The condition under which it prints (randomly tapping into a mem_map[]
                  hole and not being able to c_p_a() there) is valid behavior and not
                  interesting to report.
      
                  Remove it.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      
               100.0% arch/x86/mm/
      
      or something much more complex like
      
              commit e231c2e...
              Author: David Howells <dhowells@redhat.com>
              Date:   Thu Feb 7 00:15:26 2008 -0800
      
                  Convert ERR_PTR(PTR_ERR(p)) instances to ERR_CAST(p)
      
      	  20.5% crypto/
      	   7.6% fs/afs/
      	   7.6% fs/fuse/
      	   7.6% fs/gfs2/
      	   5.1% fs/jffs2/
      	   5.1% fs/nfs/
      	   5.1% fs/nfsd/
      	   7.6% fs/reiserfs/
      	  15.3% fs/
      	   7.6% net/rxrpc/
      	  10.2% security/keys/
      
      where that latter example is an example of significant work in some
      individual fs/*/ subdirectories (like the patches to reiserfs accounting
      for 7.6% of the whole), but then discounting those individual filesystems,
      there's also 15.3% other "random" things that weren't worth reporting on
      their oen left over under fs/ in general (either in that directory itself,
      or in subdirectories of fs/ that didn't have enough changes to be reported
      individually).
      
      I'd like to stress that the "15.3% fs/" mentioned above is the stuff that
      is under fs/ but that was _not_ significant enough to report on its own.
      So the above does _not_ mean that 15.3% of the work was under fs/ per se,
      because that 15.3% does *not* include the already-reported 7.6% of afs,
      7.6% of fuse etc.
      
      If you want to enable "cumulative" directory statistics, you can use the
      "--cumulative" flag, which adds up percentages recursively even when
      they have been already reported for a sub-directory.  That cumulative
      output is disabled if *all* of the changes in one subdirectory come from
      a deeper subdirectory, to avoid repeating subdirectories all the way to
      the root.
      
      For an example of the cumulative reporting, the above commit becomes
      
      	commit e231c2e...
      	Author: David Howells <dhowells@redhat.com>
      	Date:   Thu Feb 7 00:15:26 2008 -0800
      
      	    Convert ERR_PTR(PTR_ERR(p)) instances to ERR_CAST(p)
      
      	  20.5% crypto/
      	   7.6% fs/afs/
      	   7.6% fs/fuse/
      	   7.6% fs/gfs2/
      	   5.1% fs/jffs2/
      	   5.1% fs/nfs/
      	   5.1% fs/nfsd/
      	   7.6% fs/reiserfs/
      	  61.5% fs/
      	   7.6% net/rxrpc/
      	  10.2% security/keys/
      
      in which the commit percentages now obviously add up to much more than
      100%: now the changes that were already reported for the sub-directories
      under fs/ are then cumulatively included in the whole percentage of fs/
      (ie now shows 61.5% as opposed to the 15.3% without the cumulative
      reporting).
      
      The default reporting limit has been arbitrarily set at 3%, which seems
      to be a pretty good cut-off, but you can specify the cut-off manually by
      giving it as an option parameter (eg "--dirstat=5" makes the cut-off be
      at 5% instead)
      
      NOTE! The percentages are purely about the total lines added and removed,
      not anything smarter (or dumber) than that. Also note that you should not
      generally expect things to add up to 100%: not only does it round down, we
      don't report leftover scraps (they add up to the top-level change count,
      but we don't even bother reporting that, it only reports subdirectories).
      
      Quite frankly, as a top-level manager this is really convenient for me,
      but it's going to be very boring for git itself since there are few
      subdirectories. Also, don't expect things to make tons of sense if you
      combine this with "-M" and there are cross-directory renames etc.
      
      But even for git itself, you can get some fun statistics. Try out
      
              git log --dirstat
      
      and see the occasional mentions of things like Documentation/, git-gui/,
      gitweb/ and gitk-git/. Or try out something like
      
              git diff --dirstat v1.5.0..v1.5.4
      
      which does kind of git an overview that shows *something*. But in general,
      the output is more exciting for big projects with deeper structure, and
      doing a
      
              git diff --dirstat v2.6.24..v2.6.25-rc1
      
      on the kernel is what I actually wrote this for!
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      7df7c019
  2. 12 2月, 2008 39 次提交