{"thread":{"id":"43117","subject":"Re: jgit performance update","startedAt":"2006-12-03T04:59:53Z","lastAt":"2006-12-04T20:35:49Z","messageCount":16,"participants":["Juergen Stuber","Jakub Narebski","Shawn Pearce","Robin Rosenberg","sf","Linus Torvalds"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"297021","messageId":"20061203045953.GE26668@spearce.org","threadId":"43117","inReplyTo":null,"subject":"jgit performance update","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-03T04:59:53Z","receivedAt":"2006-12-03T04:59:53Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"With the help of Robin Rosenberg I've been able to make jgit's log\noperation run (on average) within a few milliseconds of core Git.\n\nWalking the 50,000 most recent commits from the Mozilla trunk[1]:\n\n $ time git rev-list --max-count=50000 HEAD >/dev/null\n\n core Git: 1.882s (average)\n jgit: 1.932s (average)\n\n (times are with hot cache and from repeated executions)\n\nI think that is actually pretty good given that jgit is written\nin Java using a fairly object-oriented design and has to deal with\nsome of the limitations of the language.\n\nOne of the biggest annoyances has been the fact that although Java\n1.4 offers a way to mmap a file into the process, the overhead to\naccess that data seems to be far higher than just reading the file\ncontent into a very large byte array, especially if we are going\nto access that file content multiple times. So jgit performs worse\nthan core Git early on while it copies everything from the OS buffer\ncache into the Java process, but then performs reasonably well once\nthe internal cache is hot. On the other hand using the mmap call\nreduces early latency but hurts the access times so much that we're\ntalking closer to 3s average read times for the same log operation.\n\nAnyway, jgit is now hopefully fast enough that we can start to build\nsome real functionality on top of it, and not need to wait several\nminutes for answers from those features while debugging them. :)\n\n\n**1** This is the pack file from Jon Smirl's import attempt.\n\n-- \n"},{"id":"298357","messageId":"200612031455.48032.robin.rosenberg.lists@dewire.com","threadId":"43117","inReplyTo":"20061203045953.GE26668@spearce.org","subject":"Re: jgit performance update","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2006-12-03T13:55:47Z","receivedAt":"2006-12-03T13:55:47Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"söndag 03 december 2006 05:59 skrev Shawn Pearce:\n> With the help of Robin Rosenberg I've been able to make jgit's log\n> operation run (on average) within a few milliseconds of core Git.\n>\n> Walking the 50,000 most recent commits from the Mozilla trunk[1]:\n>\n> $ time git rev-list --max-count=50000 HEAD >/dev/null\n>\n> core Git: 1.882s (average)\n> jgit: 1.932s (average)\n>\n> (times are with hot cache and from repeated executions)\nNice indeed. That was a ten-fold improvement for getting my full history. \n\nSo, just go on to the next case. I added filtering on filenames (yes, \nCVS-induced brain damage, I should track the content. next version. filenames \nare so much handier to work with). That gives me 4.5s to retrieve a filtered \nhistory (from 10800 commits).Half of the time is spent in re-sorting tree \nentries. Is that really necessary?\n\n> I think that is actually pretty good given that jgit is written\n> in Java using a fairly object-oriented design and has to deal with\n> some of the limitations of the language.\nMost of java's slowness comes from the programmers using it. (Lutz Prechelt. \nTechnical opinion: comparing Java vs. C/C++ efficiency differences to \ninterpersonal differences. ACM, Vol 42,#10, 1999)\n\n> One of the biggest annoyances has been the fact that although Java \n> 1.4 offers a way to mmap a file into the process, the overhead to\n> access that data seems to be far higher than just reading the file\n> content into a very large byte array, especially if we are going\n> to access that file content multiple times. So jgit performs worse\n> than core Git early on while it copies everything from the OS buffer\n> cache into the Java process, but then performs reasonably well once\n> the internal cache is hot. On the other hand using the mmap call\n> reduces early latency but hurts the access times so much that we're\n> talking closer to 3s average read times for the same log operation.\n\nHave you tried that with difference JVM's?\n\n"},{"id":"294243","messageId":"ekumdo$imo$1@sea.gmane.org","threadId":"43117","inReplyTo":"200612031455.48032.robin.rosenberg.lists@dewire.com","subject":"Re: jgit performance update","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-03T14:19:36Z","receivedAt":"2006-12-03T14:19:36Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Robin Rosenberg wrote:\n\n> söndag 03 december 2006 05:59 skrev Shawn Pearce:\n>\n>> With the help of Robin Rosenberg I've been able to make jgit's log\n>> operation run (on average) within a few milliseconds of core Git.\n>>\n>> Walking the 50,000 most recent commits from the Mozilla trunk[1]:\n>>\n>> $ time git rev-list --max-count=50000 HEAD >/dev/null\n>>\n>> core Git: 1.882s (average)\n>> jgit: 1.932s (average)\n>>\n>> (times are with hot cache and from repeated executions)\n> Nice indeed. That was a ten-fold improvement for getting my full history. \n> \n> So, just go on to the next case. I added filtering on filenames (yes, \n> CVS-induced brain damage, I should track the content. next version. filenames \n> are so much handier to work with).\n\nGit uses as _revision limiter_, not as output filter. Shouldn't\njgit do the same?\n\nP.S. What is the status of --follow option?\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"295326","messageId":"200612031653.04019.robin.rosenberg.lists@dewire.com","threadId":"43117","inReplyTo":"ekumdo$imo$1@sea.gmane.org","subject":"Re: jgit performance update","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2006-12-03T15:53:02Z","receivedAt":"2006-12-03T15:53:02Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"söndag 03 december 2006 15:19 skrev Jakub Narebski:\n> Robin Rosenberg wrote:\n> > CVS-induced brain damage, I should track the content. next version.\n> > filenames are so much handier to work with).\n>\n> Git uses as _revision limiter_, not as output filter. Shouldn't\n> jgit do the same?\nIt's egit, i.e. the eclipse plugin I'm referring to so it's a user interface \nthing and it uses the path name. \n\n"},{"id":"297673","messageId":"Pine.LNX.4.64.0612030938140.3476@woody.osdl.org","threadId":"43117","inReplyTo":"20061203045953.GE26668@spearce.org","subject":"Re: jgit performance update","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-12-03T17:45:15Z","receivedAt":"2006-12-03T17:45:15Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 2 Dec 2006, Shawn Pearce wrote:\n>\n> With the help of Robin Rosenberg I've been able to make jgit's log\n> operation run (on average) within a few milliseconds of core Git.\n\nVery good. Are we any closer to actually having an eclipse plugin then?\n\nNot that I've ever actually used eclipse, but maybe I should try it, just \nto see what those strange user-land people actually do. I'll be a \nveritable Jane Goodall..\n\n> Walking the 50,000 most recent commits from the Mozilla trunk[1]:\n> \n> $ time git rev-list --max-count=50000 HEAD >/dev/null\n> \n> core Git: 1.882s (average)\n> jgit: 1.932s (average)\n> \n> (times are with hot cache and from repeated executions)\n\nNow, the _interesting_ case in many ways is not \"--max-count\", but the \nrevision limiter. It _should_ be equally fast, but if you've done \nsomething wrong, it won't be.\n\nIOW, try to find a point far enough back in time to get about the same \nnumber of commits, and then do\n\n\ttime git rev-list ..HEAD >/dev/null\n\nbecause one of the things you want to handle is ranges, more so than \nsimple counts. And that is not only the much more common case, it also \ntriggers a few cases that you probably didn't trigger with the regular \n\"list the first 50 thousand commits\" case.\n\n> One of the biggest annoyances has been the fact that although Java\n> 1.4 offers a way to mmap a file into the process, the overhead to\n> access that data seems to be far higher than just reading the file\n> content into a very large byte array, especially if we are going\n> to access that file content multiple times.\n\nThat must suck for big packed repositories. What JVM and other environment \nare you using?\n\nAlso, I have to say, one of the reasons I'm interested in your project is \nthat I've never done any Java programming, because quite frankly, I've \nnever had any reason what-so-ever to do so. But if there is some simple \nsetup, and you have jgit exposed somewhere as a git archive, I'd love to \ntake a look, if only to finally learn more about Java.\n\n"},{"id":"296470","messageId":"ekv34g$mck$1@sea.gmane.org","threadId":"43117","inReplyTo":"Pine.LNX.4.64.0612030938140.3476@woody.osdl.org","subject":"Re: jgit performance update","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-03T17:56:33Z","receivedAt":"2006-12-03T17:56:33Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Linus Torvalds wrote:\n\n> Also, I have to say, one of the reasons I'm interested in your project is \n> that I've never done any Java programming, because quite frankly, I've \n> never had any reason what-so-ever to do so. But if there is some simple \n> setup, and you have jgit exposed somewhere as a git archive, I'd love to \n> take a look, if only to finally learn more about Java.\n\nGitWiki tells us about egit/jgit repository at\n http://www.spearce.org/projects/scm/egit.git\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"296477","messageId":"457347E1.2020800@stephan-feder.de","threadId":"43117","inReplyTo":"20061203045953.GE26668@spearce.org","subject":"Re: jgit performance update","fromName":"sf","fromEmail":"sf-gmane@stephan-feder.de","sentAt":"2006-12-03T21:55:45Z","receivedAt":"2006-12-03T21:55:45Z","isPatch":false,"sender":{"key":"sf-gmane@stephan-feder.de","avatar":null},"body":"Shawn Pearce wrote:\n...\n> One of the biggest annoyances has been the fact that although Java\n> 1.4 offers a way to mmap a file into the process,\n\nBe careful with mmap:\nhttp://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4724038\n\n\nRegards\n\nStephan\n"},{"id":"295205","messageId":"20061203221602.GA15965@spearce.org","threadId":"43117","inReplyTo":"457347E1.2020800@stephan-feder.de","subject":"Re: jgit performance update","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-03T22:16:02Z","receivedAt":"2006-12-03T22:16:02Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"sf wrote:\n> Shawn Pearce wrote:\n> ...\n> > One of the biggest annoyances has been the fact that although Java\n> > 1.4 offers a way to mmap a file into the process,\n> \n> Be careful with mmap:\n> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4724038\n\nThanks. That particular bug has been of some discussion on\n#git before. I'm planning on making it a configuration flag in\n.git/config for the user to decide how much pain they want: mmap\n(with all its huge downsides) or read into byte[] (with all the\nmemory footprint that requires).\n\n-- \n"},{"id":"293868","messageId":"874psceh4z.fsf@freitag.home.jstuber.net","threadId":"43117","inReplyTo":"ekv34g$mck$1@sea.gmane.org","subject":"Re: jgit performance update","fromName":"Juergen Stuber","fromEmail":"juergen@jstuber.net","sentAt":"2006-12-03T22:42:04Z","receivedAt":"2006-12-03T22:42:04Z","isPatch":false,"sender":{"key":"juergen@jstuber.net","avatar":null},"body":"Hi Jakub,\n\nJakub Narebski writes:\n>\n> GitWiki tells us about egit/jgit repository at\n> http://www.spearce.org/projects/scm/egit.git\n\nI tried to access that with git 1.4.4.1 from Debian but \n\n% git clone http://www.spearce.org/projects/scm/egit.git\n\nhangs, the first time after \"walk e339766abc2b919e7bb396cae22ddef065821381\",\nthe second time after \"walk 9eec90ec5da239e063eaff6305d77294dc03396e\"\nwhich is the \"walk\" line just before it.\n\nThere's also the following error shortly after the start:\n\nerror: File bc01ab9e5fcd26918d7a334207183fa57ff1ce50 (http://www.spearce.org/projects/scm/egit.git/objects/75/1c8f2e504c40d1c41ebbd87d8f8968529e9c30) corrupt\n\n\nJürgen\n\n-- \nJürgen Stuber \nhttp://www.jstuber.net/\ngnupg key fingerprint = 2767 CA3C 5680 58BA 9A91 23D9 BED6 9A7A AF9E 68B4\n"},{"id":"298298","messageId":"20061203224726.GC15965@spearce.org","threadId":"43117","inReplyTo":"Pine.LNX.4.64.0612030938140.3476@woody.osdl.org","subject":"Re: jgit performance update","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-03T22:47:26Z","receivedAt":"2006-12-03T22:47:26Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Linus Torvalds wrote:\n> Very good. Are we any closer to actually having an eclipse plugin then?\n\nWe have some parts in place. But nothing that's user-ready.\n \n> > Walking the 50,000 most recent commits from the Mozilla trunk[1]:\n> \n> Now, the _interesting_ case in many ways is not \"--max-count\", but the \n> revision limiter. It _should_ be equally fast, but if you've done \n> something wrong, it won't be.\n\nWe haven't implemented a rev-list equivalent yet. That's a major\nfeature which is missing. The --max-count test was simple to put\ntogether. I really need to start thinking about replicating some\nof the features of the revision functions in core Git.\n\n> > One of the biggest annoyances has been the fact that although Java\n> > 1.4 offers a way to mmap a file into the process, the overhead to\n> > access that data seems to be far higher than just reading the file\n> > content into a very large byte array, especially if we are going\n> > to access that file content multiple times.\n> \n> That must suck for big packed repositories. What JVM and other environment \n> are you using?\n\nMac OS 10.4.8 / Java 1.4.2. It appears as though Sun isn't going\nto fix the mmap performance problems as they can't do it \"securely\".\nSo its likely to be an issue anywhere jgit gets used...\n\n> Also, I have to say, one of the reasons I'm interested in your project is \n> that I've never done any Java programming, because quite frankly, I've \n> never had any reason what-so-ever to do so. But if there is some simple \n> setup, and you have jgit exposed somewhere as a git archive, I'd love to \n> take a look, if only to finally learn more about Java.\n\nOf course its in Git. :-)\n\nThere's no webpage here, but you can clone it:\n\n http://www.spearce.org/projects/scm/egit.git\n\nThe code you would recognize most is in org.spearce.jgit/.../lib.\nE.g. BinaryDelta.java came from patch-delta.c in core Git.\nRepository has some of the functionality of sha1_file.c, the pack\nreading code is in PackFile.java.\n\n-- \n"},{"id":"295314","messageId":"20061203225947.GD15965@spearce.org","threadId":"43117","inReplyTo":"200612031455.48032.robin.rosenberg.lists@dewire.com","subject":"Re: jgit performance update","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-03T22:59:48Z","receivedAt":"2006-12-03T22:59:48Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Robin Rosenberg wrote:\n> So, just go on to the next case. I added filtering on filenames (yes, \n> CVS-induced brain damage, I should track the content. next version. filenames \n> are so much handier to work with). That gives me 4.5s to retrieve a filtered \n> history (from 10800 commits).Half of the time is spent in re-sorting tree \n> entries. Is that really necessary?\n\nYea, I was looking at that code while doing the other performance\nimprovements and thought it might start to become a bottleneck. I\nguess I was right.\n\nWhat is happening here is jgit wants to store the items in the tree\nin name ordering, but Git stores the items in the tree sorted such\nthat subtrees sort with a '/' on the end of their name. This is a\ndifferent ordering...\n\nThe reason I'm resorting them is so we can find an entry without\nknowing what its type is first. Looks like that's going to have\nto change somehow.\n \n> Most of java's slowness comes from the programmers using it. (Lutz Prechelt. \n> Technical opinion: comparing Java vs. C/C++ efficiency differences to \n> interpersonal differences. ACM, Vol 42,#10, 1999)\n\nYes, that was clearly the case here with jgit! :-)\n\n_This_ programmer made jgit slow. Learned from the mistake, and\nmade it faster.\n \n> > One of the biggest annoyances has been the fact that although Java \n> > 1.4 offers a way to mmap a file into the process, the overhead to\n> > access that data seems to be far higher than just reading the file\n> > content into a very large byte array, especially if we are going\n> > to access that file content multiple times. So jgit performs worse\n> > than core Git early on while it copies everything from the OS buffer\n> > cache into the Java process, but then performs reasonably well once\n> > the internal cache is hot. On the other hand using the mmap call\n> > reduces early latency but hurts the access times so much that we're\n> > talking closer to 3s average read times for the same log operation.\n> \n> Have you tried that with difference JVM's?\n\nNo, I'm on Mac OS X so I don't have a huge JVM selection (that I\nknow of). And I haven't tried jgit or egit on any other system yet.\n\n-- \n"},{"id":"295785","messageId":"20061203230627.GF15965@spearce.org","threadId":"43117","inReplyTo":"200612031653.04019.robin.rosenberg.lists@dewire.com","subject":"Re: jgit performance update","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-03T23:06:27Z","receivedAt":"2006-12-03T23:06:27Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Robin Rosenberg wrote:\n> söndag 03 december 2006 15:19 skrev Jakub Narebski:\n> > Robin Rosenberg wrote:\n> > > CVS-induced brain damage, I should track the content. next version.\n> > > filenames are so much handier to work with).\n> >\n> > Git uses as _revision limiter_, not as output filter. Shouldn't\n> > jgit do the same?\n> It's egit, i.e. the eclipse plugin I'm referring to so it's a user interface \n> thing and it uses the path name. \n\nJakub's point is that \"git log -- a\" lists only the revisions\nwhich affect path 'a'. Once those revisions have been selected\nthen output begins. The 'a' gets reapplied as an output filter to\nonly show changes relevant to file 'a', but its very much a revision\nfilter during the revision listing process.\n\n-- \n"},{"id":"296999","messageId":"200612040039.00315.robin.rosenberg.lists@dewire.com","threadId":"43117","inReplyTo":"874psceh4z.fsf@freitag.home.jstuber.net","subject":"Re: jgit performance update","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2006-12-03T23:39:00Z","receivedAt":"2006-12-03T23:39:00Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"söndag 03 december 2006 23:42 skrev Juergen Stuber:\n> Hi Jakub,\n>\n> Jakub Narebski writes:\n> > GitWiki tells us about egit/jgit repository at\n> > http://www.spearce.org/projects/scm/egit.git\n>\n> I tried to access that with git 1.4.4.1 from Debian but\n>\n> % git clone http://www.spearce.org/projects/scm/egit.git\n>\n> hangs, the first time after \"walk\n> e339766abc2b919e7bb396cae22ddef065821381\", the second time after \"walk\n> 9eec90ec5da239e063eaff6305d77294dc03396e\" which is the \"walk\" line just\n> before it.\nWorks fine here. (git 1.4.4.gf05d).\n>\n> There's also the following error shortly after the start:\n>\n> error: File bc01ab9e5fcd26918d7a334207183fa57ff1ce50\n> (http://www.spearce.org/projects/scm/egit.git/objects/75/1c8f2e504c40d1c41e\n>bbd87d8f8968529e9c30) corrupt\n\nUnfortunately, messages about corrupt objects are \"normal\" with clone over \nhttp. I'm not sure it has to be that way though. Run git-fsck-objects to make \nsure there are no errors. The hangs aren't normal.\n\n-- robin\n\n"},{"id":"297890","messageId":"ekvoan$lst$1@sea.gmane.org","threadId":"43117","inReplyTo":"200612040039.00315.robin.rosenberg.lists@dewire.com","subject":"Re: jgit performance update","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-03T23:58:17Z","receivedAt":"2006-12-03T23:58:17Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Robin Rosenberg wrote:\n\n> söndag 03 december 2006 23:42 skrev Juergen Stuber:\n>>\n>> Jakub Narebski writes:\n>>>\n>>> GitWiki tells us about egit/jgit repository at\n>>> http://www.spearce.org/projects/scm/egit.git\n>>\n>> I tried to access that with git 1.4.4.1 from Debian but\n>>\n>> % git clone http://www.spearce.org/projects/scm/egit.git\n>>\n>> hangs, the first time after \"walk\n>> e339766abc2b919e7bb396cae22ddef065821381\", the second time after \"walk\n>> 9eec90ec5da239e063eaff6305d77294dc03396e\" which is the \"walk\" line just\n>> before it.\n>\n> Works fine here. (git 1.4.4.gf05d).\nWorks fine here. (git 1.4.4.1)\n\n>> There's also the following error shortly after the start:\n>>\n>> error: File bc01ab9e5fcd26918d7a334207183fa57ff1ce50\n>> (http://www.spearce.org/projects/scm/egit.git/objects/75/1c8f2e504c40d1c41e\n>>bbd87d8f8968529e9c30) corrupt\n> \n> Unfortunately, messages about corrupt objects are \"normal\" with clone over \n> http. I'm not sure it has to be that way though. Run git-fsck-objects to make \n> sure there are no errors. The hangs aren't normal.\n\nI got:\n$ git clone http://www.spearce.org/projects/scm/egit.git\n[...]\n got 73ed47b2bb1fa5978f7368775979e5c85d354c5a\n error: File 2332eacf114debb7a27d138811197f06eb262551 \n (http://www.spearce.org/projects/scm/egit.git/objects/75/1c8f2e504c40d1c41ebbd87d8f8968529e9c30) corrupt\n Getting pack list for http://www.spearce.org/projects/scm/egit.git/\n got afefbe09bacc08adb75fb46200a973001c6b02de\n[...]\n walk c1f287cb19b9910af19756cf29c08b1fda75da8c\n Some loose object were found to be corrupt, but they might be just\n a false '404 Not Found' error message sent with incorrect HTTP\n status code. Suggest running git fsck-objects.\n got eab86de8ac23e2e77878835007724146fdd83796\n$ git fsck-objects --unreachable --full --strict ;# returns no errors\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"295193","messageId":"20061204004610.GA16706@spearce.org","threadId":"43117","inReplyTo":"ekvoan$lst$1@sea.gmane.org","subject":"Re: jgit performance update","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-04T00:46:10Z","receivedAt":"2006-12-04T00:46:10Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Jakub Narebski wrote:\n> I got:\n> $ git clone http://www.spearce.org/projects/scm/egit.git\n> [...]\n> got 73ed47b2bb1fa5978f7368775979e5c85d354c5a\n> error: File 2332eacf114debb7a27d138811197f06eb262551 \n> (http://www.spearce.org/projects/scm/egit.git/objects/75/1c8f2e504c40d1c41ebbd87d8f8968529e9c30) corrupt\n> Getting pack list for http://www.spearce.org/projects/scm/egit.git/\n> got afefbe09bacc08adb75fb46200a973001c6b02de\n> [...]\n> walk c1f287cb19b9910af19756cf29c08b1fda75da8c\n> Some loose object were found to be corrupt, but they might be just\n> a false '404 Not Found' error message sent with incorrect HTTP\n> status code. Suggest running git fsck-objects.\n> got eab86de8ac23e2e77878835007724146fdd83796\n> $ git fsck-objects --unreachable --full --strict ;# returns no errors\n\nRight. My web server doesn't send back 404 messages when an object\nisn't found (but is packed). Thus the error...\n\nI've setup a project on repo.or.cz:\n\n http://repo.or.cz/w/egit.git\n\n\n-- \n"},{"id":"296682","messageId":"87ac23qtzu.fsf@freitag.home.jstuber.net","threadId":"43117","inReplyTo":"200612040039.00315.robin.rosenberg.lists@dewire.com","subject":"Re: jgit performance update","fromName":"Juergen Stuber","fromEmail":"juergen@jstuber.net","sentAt":"2006-12-04T20:35:49Z","receivedAt":"2006-12-04T20:35:49Z","isPatch":false,"sender":{"key":"juergen@jstuber.net","avatar":null},"body":"Hej Robin,\n\nRobin Rosenberg writes:\n> söndag 03 december 2006 23:42 skrev Juergen Stuber:\n>> Jakub Narebski writes:\n>> > GitWiki tells us about egit/jgit repository at\n>> > http://www.spearce.org/projects/scm/egit.git\n>>\n>> I tried to access that with git 1.4.4.1 from Debian but\n>>\n>> % git clone http://www.spearce.org/projects/scm/egit.git\n>>\n>> hangs, the first time after \"walk\n>> e339766abc2b919e7bb396cae22ddef065821381\", the second time after \"walk\n>> 9eec90ec5da239e063eaff6305d77294dc03396e\" which is the \"walk\" line just\n>> before it.\n> Works fine here. (git 1.4.4.gf05d).\n\nnow it works fine for me, too.\n\n\nTack\n\nJürgen\n\n-- \nJürgen Stuber \nhttp://www.jstuber.net/\ngnupg key fingerprint = 2767 CA3C 5680 58BA 9A91 23D9 BED6 9A7A AF9E 68B4\n"}]}