Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030381AbWJUCMk (ORCPT ); Fri, 20 Oct 2006 22:12:40 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1030380AbWJUCMk (ORCPT ); Fri, 20 Oct 2006 22:12:40 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:61606 "EHLO ZenIV.linux.org.uk") by vger.kernel.org with ESMTP id S1030377AbWJUCMj (ORCPT ); Fri, 20 Oct 2006 22:12:39 -0400 Date: Sat, 21 Oct 2006 03:12:35 +0100 From: Al Viro To: Linus Torvalds Cc: Junio C Hamano , git@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [ANNOUNCE] GIT 1.4.3 Message-ID: <20061021021235.GA29920@ftp.linux.org.uk> References: <7vejt5xjt9.fsf@assigned-by-dhcp.cox.net> <7v4ptylfvw.fsf@assigned-by-dhcp.cox.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2090 Lines: 44 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 linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/