git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [ANNOUNCE] GIT 1.4.3

From
AVAl Viro <viro@ftp.linux.org.uk>
Date
Oct 21, 2006, 02:12 UTC
Message-ID
<20061021021235.GA29920@ftp.linux.org.uk>
In-Reply-To
<Pine.LNX.4.64.0610201709430.3962@g5.osdl.org>
On Fri, Oct 20, 2006 at 05:14:39PM -0700, Linus Torvalds wrote:
Show 10 quoted lines
> 
> 
> 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...

Previous: Anders LarsenNext: Junio C Hamano
Message 9 of 20 in “[ANNOUNCE] GIT 1.4.3”
  1. Junio C HamanoOct 18, 2006
  2. Peter EriksenOct 20, 2006
  3. Junio C HamanoOct 20, 2006
  4. Linus TorvaldsOct 21, 2006
  5. Petr BaudisOct 21, 2006
  6. Linus TorvaldsOct 21, 2006
  7. Andreas SchwabOct 21, 2006
  8. Anders LarsenOct 22, 2006
  9. Al ViroOct 21, 2006
  10. Junio C HamanoOct 21, 2006
  11. Al ViroOct 21, 2006
  12. Rene ScharfeOct 21, 2006
  13. Nicolas PitreOct 21, 2006
  14. J. Bruce FieldsOct 23, 2006
  15. A Large Angry SCMOct 23, 2006
  16. J. Bruce FieldsOct 23, 2006
  17. Junio C HamanoOct 23, 2006
  18. Petr BaudisOct 23, 2006
  19. Jon LoeligerOct 27, 2006
  20. Junio C HamanoOct 27, 2006

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.