From: Linus Torvalds Date: Fri, 28 Oct 2005 00:12:33 GMT Subject: Re: [PATCH gitweb] Visually indicating patch size with horizontal bars Message-ID: In-Reply-To: <20051027234813.GA512@pe.Belkin> On Thu, 27 Oct 2005, Chris Shoemaker wrote: > > > > * do we really want to know the number of lines? sometimes the > > number of pahts that are affected is more useful than number > > of lines when assessing the damage, which can be done with > > 'git-diff-tree --name-only'. > > That only shows the top-level names, so when 100s of files changes in > a subdir it looks just like one entry. It's ok when there's no > subdirs, but it just doesn't work when 95% of the code is under, > e.g. src/. Add the "-r" flag to do the recursive thing, ie git-diff-tree -r --name-only should do the right thing. > True. Maybe gitk and gitweb can share a cache containing the tree > diffs. Or maybe git-core can cache tree diffs? Creating them is fast enough if there is no IO. Make sure your project is packed, and you should be ok. The expensive part is the "-p" thing to create patches. If you avoid the patch creation, you should be ok. > But, in general, is there interest in a visual indicator of commit > size and/or type in gitweb? I kind of like it, but I'm not sure how useful it is, and maybe it does really want the whole patch size (not just how many files it touches). That's where caching might save your *ss. Linus