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... - 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