{"thread":{"id":"23340","subject":"[PATCH 0/7 (v5)] rev-cache","startedAt":"2010-04-05T19:57:43Z","lastAt":"2010-04-06T17:34:39Z","messageCount":3,"participants":["Nick Edelen","Björn Gustavsson","Junio C Hamano"],"isPatch":true,"patchVersion":5,"patchTotal":7},"messages":[{"id":"138666","messageId":"4BBA40B7.1060100@gmail.com","threadId":"23340","inReplyTo":null,"subject":"[PATCH 0/7 (v5)] rev-cache","fromName":"Nick Edelen","fromEmail":"sirnot@gmail.com","sentAt":"2010-04-05T19:57:43Z","receivedAt":"2010-04-05T19:57:43Z","isPatch":true,"sender":{"key":"sirnot@gmail.com","avatar":null},"body":"SUGGESTED FOR 'PU':\n\nTraversing objects is currently very costly, as every commit and tree must be\nloaded and parsed. Much time and energy could be saved by caching metadata and\ntopological info in an efficient, easily accessible manner. Furthermore, this\ncould improve git's interfacing potential, by providing a condensed summary of\na repository's commit tree.\n\nThis is a series to implement such a revision caching mechanism, aptly named\nrev-cache. The series will provide:\n - a core API to manipulate and traverse caches\n - an integration into the internal revision walker\n - a porcelain front-end providing access to users and (shell) applications\n - a series of tests to verify/demonstrate correctness\n - documentation of the API, porcelain and core concepts\n\nIn cold starts rev-cache has sped up packing and walking by a factor of 4, and\nover twice that on warm starts. The mechanism is minimally intrusive: most of\nthe changes take place in seperate files, and only a handful of git's existing\nfunctions are modified.\n\nSlides from the presentation I gave at GitTogether'09 give a good overview of\nthe mechanism, usage and performance of rev-cache. (well, they complement the\ndocumentation well. they're a bit bare without the dialogue...) You can find\nthem at http://www.flickr.com/photos/sirnot/sets/72157623652754819/\n\nThe patchset is structured so that each patchfile represents a fully\nfunctional, incremental development of rev-cache. Unfortunately the addition\nof several files makes for some obscenely large patchfiles. I apologize and\nregret that this is somewhat unavoidable; my only consolation is that\npatchfiles are less 'patches' and more additions of files.\n\nHope you find this useful.\n\n - Nick\n\n---\nHi everyone. I'm sorry about the (very) belated patchset -- University has a\ntendency of being very absorbing. It's spring break now though, so I've\nfinally got around to finalizing rev-cache! The only significant change from\nlast time (besides the bugfixes) is how structures are read/written --\nexcessive care is now taken to ensure a standardized file format.\n\nThis time round I've also got some swanky slides I made for GitTogether. Hehe.\n\n Documentation/git-rev-cache.txt | 194 +++\n Documentation/technical/rev-cache.txt | 634 +++++++++\n Makefile | 2 +\n builtin.h | 1 +\n builtin/gc.c | 9 +\n builtin/rev-cache.c | 339 +++++\n command-list.txt | 1 +\n commit.c | 36 +-\n git.c | 1 +\n list-objects.c | 46 +-\n object.h | 3 +-\n rev-cache.c | 2468 +++++++++++++++++++++++++++++++++\n rev-cache.h | 123 ++\n revision.c | 90 +-\n revision.h | 44 +-\n t/t6019-rev-cache-list.sh | 263 ++++\n 16 files changed, 4227 insertions(+), 27 deletions(-)\n create mode 100644 Documentation/git-rev-cache.txt\n create mode 100644 Documentation/technical/rev-cache.txt\n create mode 100644 builtin/rev-cache.c\n create mode 100644 rev-cache.c\n create mode 100644 rev-cache.h\n create mode 100644 t/t6019-rev-cache-list.sh\n"},{"id":"138734","messageId":"j2t6672d0161004060314j526e6d4q905bf427063b605f@mail.gmail.com","threadId":"23340","inReplyTo":"7vaathjcru.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 0/7 (v5)] rev-cache","fromName":"Björn Gustavsson","fromEmail":"bgustavsson@gmail.com","sentAt":"2010-04-06T10:14:59Z","receivedAt":"2010-04-06T10:14:59Z","isPatch":true,"sender":{"key":"bgustavsson@gmail.com","avatar":"https://avatars.githubusercontent.com/u/74840?v=4"},"body":"2010/4/6 Junio C Hamano :\n\n> So don't take this as a complaint; it is unfair to call this a bug. But\n> it certainly feels like it is in the same area that can be improved.\n\nYes, I agree. I'll have a look.\n\n-- \nBjörn Gustavsson, Erlang/OTP, Ericsson AB\n"},{"id":"138770","messageId":"7vd3yciixc.fsf@alter.siamese.dyndns.org","threadId":"23340","inReplyTo":"j2t6672d0161004060314j526e6d4q905bf427063b605f@mail.gmail.com","subject":"Re: [PATCH 0/7 (v5)] rev-cache","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-04-06T17:34:39Z","receivedAt":"2010-04-06T17:34:39Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"In case people are wondering what the message Björn is responding to\nsaid...\n\n From: Junio C Hamano \n Subject: Re: [PATCH 0/7 (v5)] rev-cache\n Date: Mon, 05 Apr 2010 23:49:57 -0700\n References: <4BBA40B7.1060100@gmail.com>\n Message-ID: <7vaathjcru.fsf@alter.siamese.dyndns.org>\n\n Björn, I thought your \"apply --whitespace=fix\" patch was supposed to be\n able to cope with this series whose [2/7] introduces a new file with a\n trailing blank line \"t/t6019-rev-cache-list.sh\" (which is correctly fixed\n not to have that extra blank line at the end), and then a subsequent patch\n in the series [3/7] still tries to apply a patch assuming that the extra\n blank line was still there.\n\n But that is apparently not the case. I think your series dealt only for\n the cases where the additional contents came _after_ the fixed-and-gone\n blank lines, and never dealt with the case where such lines appear in the\n context.\n\nThe message didn't go to vger because I botched while editing To/Cc lines.\n"}]}