Re: [ANNOUNCE] GIT 1.4.3

[Al Viro <viro@ftp.linux.org.uk>]

On Fri, Oct 20, 2006 at 05:14:39PM -0700, Linus Torvalds wrote:
> 
> 
> On Fri, 20 Oct 2006, Junio C Hamano wrote:
> > 
> > I am considering the following to address irritation some people
> > (including me, actually) are experiencing with this change when
> > viewing a small (or no) diff.  Any objections?
> 
> Not from me. I use "git diff" just to check that the tree is empty, and 
> the fact that it now throws me into an empty pager is irritating.

Speaking of irritations...  There is a major (and AFAICS fixable)
suckitude in git-cherry.  Basically, what it does is
	* use git-rev-list to find commits on our branches
	* do git-diff-tree -p for each commit
	* do git-patch-id on each delta
	* compare sets.
For one thing, there are better ways to do set comparison than creating
a file for each element in one set and going through another checking
if corresponding files exist (join(1) and sort(1) or just use perl hashes).
That one is annoying on journalling filesystems (a lot of files being
created, read and removed - fsckloads of disk traffic), but it's actually
not the worst problem.

Far more annoying is that we keep recalculating git-diff-tree -p | git-patch-id
again and again; try to do git cherry on a dozen short branches forked at
2.6.18 and you'll see the damn thing recalculated a dozen of times for
each commit from 2.6.18 to current.  It's not cheap, to put it mildly.

git-rev-list ^v2.6.18 HEAD|while read i; do git-diff-tree -p $i; done |git-patch-id >/dev/null

out of hot cache on 2GHz amd64 box (Athlon 64 3400+) takes 3 minutes of
wall time.  Repeat that for each branch and it's starting to get old very
fast.

Note that we are calculating a function of commit; it _never_ changes.
Even if we don't just calculate and memorize it at commit time, a cache
somewhere under .git would speed the things up a lot...