linux-kernel - Re: [ANNOUNCE] GIT 1.4.3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 21 Oct 2006 03:12:35 +0100
From:	Al Viro <viro@....linux.org.uk>
To:	Linus Torvalds <torvalds@...l.org>
Cc:	Junio C Hamano <junkio@....net>, git@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [ANNOUNCE] GIT 1.4.3

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/