summaryrefslogtreecommitdiff
path: root/sha1_file.c
AgeCommit message (Collapse)AuthorFilesLines
2007-08-25Don't segfault if we failed to inflate a packed deltaLibravatar Shawn O. Pearce1-0/+4
Under some types of packfile corruption the zlib stream holding the data for a delta within a packfile may fail to inflate, due to say a CRC failure within the compressed data itself. When this occurs the unpack_compressed_entry function will return NULL as a signal to the caller that the data is not available. Unfortunately we then tried to use that NULL as though it referenced a memory location where a delta was stored and tried to apply it to the delta base. Loading a byte from the NULL address typically causes a SIGSEGV. cate on #git noticed this failure in `git fsck --full` where the call to verify_pack() first noticed that the packfile was corrupt by finding that the packfile's SHA-1 did not match the raw data of the file. After finding this fsck went ahead and tried to verify every object within the packfile, even though the packfile was already known to be bad. If we are going to shovel bad data at the delta unpacking code, we better handle it correctly. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-14Avoid ambiguous error message if pack.idx header is wrongLibravatar Luiz Fernando N. Capitulino1-2/+2
Print the index version when an error occurs so the user knows what type of header (and size) we thought the index should have had. Signed-off-by: Luiz Fernando N. Capitulino <lcapitulino@mandriva.com.br> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-18Rename read_pipe() with read_fd() and make its buffer nul-terminated.Libravatar Carlos Rica1-6/+15
The new name is closer to the purpose of the function. A NUL-terminated buffer makes things easier when callers need that. Since the function returns only the memory written with data, almost always allocating more space than needed because final size is unknown, an extra NUL terminating the buffer is harmless. It is not included in the returned size, so the function remains working as before. Also, now the function allows the buffer passed to be NULL at first, and alloc_nr is now used for growing the buffer, instead size=*2. Signed-off-by: Carlos Rica <jasampler@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-03Merge branch 'maint'Libravatar Junio C Hamano1-3/+13
* maint: Document -<n> for git-format-patch glossary: add 'reflog' diff --no-index: fix --name-status with added files Don't smash stack when $GIT_ALTERNATE_OBJECT_DIRECTORIES is too long
2007-07-03Don't smash stack when $GIT_ALTERNATE_OBJECT_DIRECTORIES is too longLibravatar Jim Meyering1-3/+13
There is no restriction on the length of the name returned by get_object_directory, other than the fact that it must be a stat'able git object directory. That means its name may have length up to PATH_MAX-1 (i.e., often 4095) not counting the trailing NUL. Combine that with the assumption that the concatenation of that name and suffixes like "/info/alternates" and "/pack/---long-name---.idx" will fit in a buffer of length PATH_MAX, and you see the problem. Here's a fix: sha1_file.c (prepare_packed_git_one): Lengthen "path" buffer so we are guaranteed to be able to append "/pack/" without checking. Skip any directory entry that is too long to be appended. (read_info_alternates): Protect against a similar buffer overrun. Before this change, using the following admittedly contrived environment setting would cause many git commands to clobber their stack and segfault on a system with PATH_MAX == 4096: t=$(perl -e '$s=".git/objects";$n=(4096-6-length($s))/2;print "./"x$n . $s') export GIT_ALTERNATE_OBJECT_DIRECTORIES=$t touch g ./git-update-index --add g If you run the above commands, you'll soon notice that many git commands now segfault, so you'll want to do this: unset GIT_ALTERNATE_OBJECT_DIRECTORIES Signed-off-by: Jim Meyering <jim@meyering.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-26Merge branch 'maint'Libravatar Junio C Hamano1-1/+4
* maint: config: Change output of --get-regexp for valueless keys config: Complete documentation of --get-regexp cleanup merge-base test script Fix zero-object version-2 packs Ignore submodule commits when fetching over dumb protocols
2007-06-26Fix zero-object version-2 packsLibravatar Linus Torvalds1-1/+4
A pack-file can get created without any objects in it (to transfer "no data" - which can happen if you use a reference git repo, for example, or just otherwise just end up transferring only branch head information and already have all the objects themselves). And while we probably should never create an index for such a pack, if we do (and we do), the index file size sanity checking was incorrect. This fixes it. Reported-and-tested-by: Jocke Tjernlund <tjernlund@tjernlund.se> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-13More staticLibravatar Junio C Hamano1-1/+1
There still are quite a few symbols that ought to be static. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-13-Wold-style-definition fixLibravatar Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-07War on whitespaceLibravatar Junio C Hamano1-4/+4
This uses "git-apply --whitespace=strip" to fix whitespace errors that have crept in to our source files over time. There are a few files that need to have trailing whitespaces (most notably, test vectors). The results still passes the test, and build result in Documentation/ area is unchanged. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-02Merge branch 'sp/pack'Libravatar Junio C Hamano1-5/+38
* sp/pack: Style nit - don't put space after function names Ensure the pack index is opened before access Simplify index access condition in count-objects, pack-redundant Test for recent rev-parse $abbrev_sha1 regression rev-parse: Identify short sha1 sums correctly. Attempt to delay prepare_alt_odb during get_sha1 Micro-optimize prepare_alt_odb Lazily open pack index files on demand
2007-05-31Merge branch 'maint'Libravatar Junio C Hamano1-1/+1
* maint: git-config: Improve documentation of git-config file handling git-config: Various small fixes to asciidoc documentation decode_85(): fix missing return. fix signed range problems with hex conversions
2007-05-31Merge branch 'maint-1.5.1' into maintLibravatar Junio C Hamano1-1/+1
* maint-1.5.1: git-config: Improve documentation of git-config file handling git-config: Various small fixes to asciidoc documentation decode_85(): fix missing return. fix signed range problems with hex conversions
2007-05-30always start looking up objects in the last used pack firstLibravatar Nicolas Pitre1-4/+18
Jon Smirl said: | Once an object reference hits a pack file it is very likely that | following references will hit the same pack file. So first place to | look for an object is the same place the previous object was found. This is indeed a good heuristic so here it is. The search always start with the pack where the last object lookup succeeded. If the wanted object is not available there then the search continues with the normal pack ordering. To test this I split the Linux repository into 66 packs and performed a "time git-rev-list --objects --all > /dev/null". Best results are as follows: Pack Sort w/o this patch w/ this patch ------------------------------------------------------------- recent objects last 26.4s 20.9s recent objects first 24.9s 18.4s This shows that the pack order based on object age has some influence, but that the last-used-pack heuristic is even more significant in reducing object lookup. Signed-off-by: Nicolas Pitre <nico@cam.org> --- Note: the --max-pack-size to git-repack currently produces packs with old objects after those containing recent objects. The pack sort based on filesystem timestamp is therefore backward for those. This needs to be fixed of course, but at least it made me think about this variable for the test. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-30fix signed range problems with hex conversionsLibravatar Linus Torvalds1-1/+1
Make hexval_table[] "const". Also make sure that the accessor function hexval() does not access the table with out-of-range values by declaring its parameter "unsigned char", instead of "unsigned int". With this, gcc can just generate: movzbl (%rdi), %eax movsbl hexval_table(%rax),%edx movzbl 1(%rdi), %eax movsbl hexval_table(%rax),%eax sall $4, %edx orl %eax, %edx for the code to generate a byte from two hex characters. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-29Style nit - don't put space after function namesLibravatar Shawn O. Pearce1-1/+1
Our style is to not put a space after a function name. I did here, and Junio applied the patch with the incorrect formatting. So I'm cleaning up after myself since I noticed it upon review. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-26Micro-optimize prepare_alt_odbLibravatar Shawn O. Pearce1-2/+3
Calling getenv() is not that expensive, but its also not free, and its certainly not cheaper than testing to see if alt_odb_tail is not null. Because we are calling prepare_alt_odb() from within find_sha1_file every time we cannot find an object file locally we want to skip out of prepare_alt_odb() as early as possible once we have initialized our alternate list. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-26Lazily open pack index files on demandLibravatar Shawn O. Pearce1-3/+35
In some repository configurations the user may have many packfiles, but all of the recent commits/trees/tags/blobs are likely to be in the most recent packfile (the one with the newest mtime). It is therefore common to be able to complete an entire operation by accessing only one packfile, even if there are 25 packfiles available to the repository. Rather than opening and mmaping the corresponding .idx file for every pack found, we now only open and map the .idx when we suspect there might be an object of interest in there. Of course we cannot known in advance which packfile contains an object, so we still need to scan the entire packed_git list to locate anything. But odds are users want to access objects in the most recently created packfiles first, and that may be all they ever need for the current operation. Junio observed in b867092f that placing recent packfiles before older ones can slightly improve access times for recent objects, without degrading it for historical object access. This change improves upon Junio's observations by trying even harder to avoid the .idx files that we won't need. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-20Merge branch 'np/pack'Libravatar Junio C Hamano1-36/+11
* np/pack: deprecate the new loose object header format make "repack -f" imply "pack-objects --no-reuse-object" allow for undeltified objects not to be reused
2007-05-15Ensure return value from xread() is always stored into an ssize_tLibravatar Johan Herland1-1/+1
This patch fixes all calls to xread() where the return value is not stored into an ssize_t. The patch should not have any effect whatsoever, other than putting better/more appropriate type names on variables. Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-10deprecate the new loose object header formatLibravatar Nicolas Pitre1-36/+11
Now that we encourage and actively preserve objects in a packed form more agressively than we did at the time the new loose object format and core.legacyheaders were introduced, that extra loose object format doesn't appear to be worth it anymore. Because the packing of loose objects has to go through the delta match loop anyway, and since most of them should end up being deltified in most cases, there is really little advantage to have this parallel loose object format as the CPU savings it might provide is rather lost in the noise in the end. This patch gets rid of core.legacyheaders, preserve the legacy format as the only writable loose object format and deprecate the other one to keep things simpler. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-25Merge branch 'maint'Libravatar Junio C Hamano1-5/+5
* maint: Start preparing for 1.5.1.3 Sanitize @to recipients. git-svn: Ignore usernames in URLs in find_by_url Document --dry-run and envelope-sender for git-send-email. Allow users to optionally specify their envelope sender. Ensure clean addresses are always used with Net::SMTP Validate @recipients before using it for sendmail and Net::SMTP. Perform correct quoting of recipient names. Change the scope of the $cc variable as it is not needed outside of send_message. Debugging cleanup improvements Prefix Dry- to the message status to denote dry-runs. Document --dry-run parameter to send-email. git-svn: Don't rely on $_ after making a function call Fix handle leak in write_tree Actually handle some-low memory conditions Conflicts: RelNotes git-send-email.perl
2007-04-25Actually handle some-low memory conditionsLibravatar Shawn O. Pearce1-5/+5
Tim Ansell discovered his Debian server didn't permit git-daemon to use as much memory as it needed to handle cloning a project with a 128 MiB packfile. Filtering the strace provided by Tim of the rev-list child showed this gem of a sequence: open("./objects/pack/pack-*.pack", O_RDONLY|O_LARGEFILE <unfinished ...> <... open resumed> ) = 5 OK, so the packfile is fd 5... mmap2(NULL, 33554432, PROT_READ, MAP_PRIVATE, 5, 0 <unfinished ...> <... mmap2 resumed> ) = 0xb5e2d000 and we mapped one 32 MiB window from it at position 0... mmap2(NULL, 31020635, PROT_READ, MAP_PRIVATE, 5, 0x6000 <unfinished ...> <... mmap2 resumed> ) = -1 ENOMEM (Cannot allocate memory) And we asked for another window further into the file. But got denied. In Tim's case this was due to a resource limit on the git-daemon process, and its children. Now where are we in the code? We're down inside use_pack(), after we have called unuse_one_window() enough times to make sure we stay within our allowed maximum window size. However since we didn't unmap the prior window at 0xb5e2d000 we aren't exceeding the current limit (which probably was just the defaults). But we're actually down inside xmmap()... So we release the window we do have (by calling release_pack_memory), assuming there is some memory pressure... munmap(0xb5e2d000, 33554432 <unfinished ...> <... munmap resumed> ) = 0 close(5 <unfinished ...> <... close resumed> ) = 0 And that was the last window in this packfile. So we closed it. Way to go us. Our xmmap did not expect release_pack_memory to close the fd its about to map... mmap2(NULL, 31020635, PROT_READ, MAP_PRIVATE, 5, 0x6000 <unfinished ...> <... mmap2 resumed> ) = -1 EBADF (Bad file descriptor) And so the Linux kernel happily tells us f' off. write(2, "fatal: ", 7 <unfinished ...> <... write resumed> ) = 7 write(2, "Out of memory? mmap failed: Bad "..., 47 <unfinished ...> <... write resumed> ) = 47 And we report the bad file descriptor error, and not the ENOMEM, and die, claiming we are out of memory. But actually that mmap should have succeeded, as we had enough memory for that window, seeing as how we released the prior one. Originally when I developed the sliding window mmap feature I had this exact same bug in fast-import, and I dealt with it by handing in the struct packed_git* we want to open the new window for, as the caller wasn't prepared to reopen the packfile if unuse_one_window closed it. The same is true here from xmmap, but the caller doesn't have the struct packed_git* handy. So I'm using the file descriptor instead to perform the same test. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-21Merge branch 'jc/attr'Libravatar Junio C Hamano1-4/+3
* 'jc/attr': (28 commits) lockfile: record the primary process. convert.c: restructure the attribute checking part. Fix bogus linked-list management for user defined merge drivers. Simplify calling of CR/LF conversion routines Document gitattributes(5) Update 'crlf' attribute semantics. Documentation: support manual section (5) - file formats. Simplify code to find recursive merge driver. Counto-fix in merge-recursive Fix funny types used in attribute value representation Allow low-level driver to specify different behaviour during internal merge. Custom low-level merge driver: change the configuration scheme. Allow the default low-level merge driver to be configured. Custom low-level merge driver support. Add a demonstration/test of customized merge. Allow specifying specialized merge-backend per path. merge-recursive: separate out xdl_merge() interface. Allow more than true/false to attributes. Document git-check-attr Change attribute negation marker from '!' to '-'. ...
2007-04-21Merge branch 'lt/gitlink'Libravatar Junio C Hamano1-0/+3
* lt/gitlink: Tests for core subproject support Expose subprojects as special files to "git diff" machinery Fix some "git ls-files -o" fallout from gitlinks Teach "git-read-tree -u" to check out submodules as a directory Teach git list-objects logic to not follow gitlinks Fix gitlink index entry filesystem matching Teach "git-read-tree -u" to check out submodules as a directory Teach git list-objects logic not to follow gitlinks Don't show gitlink directories when we want "other" files Teach git-update-index about gitlinks Teach directory traversal about subprojects Fix thinko in subproject entry sorting Teach core object handling functions about gitlinks Teach "fsck" not to follow subproject links Add "S_IFDIRLNK" file mode infrastructure for git links Add 'resolve_gitlink_ref()' helper function Avoid overflowing name buffer in deep directory structures diff-lib: use ce_mode_from_stat() rather than messing with modes manually
2007-04-20Simplify calling of CR/LF conversion routinesLibravatar Alex Riesen1-4/+3
Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-16add get_size_from_delta()Libravatar Nicolas Pitre1-34/+39
... which consists of existing code split out of packed_delta_info() for other callers to use it as well. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-10Teach core object handling functions about gitlinksLibravatar Linus Torvalds1-0/+3
This teaches the really fundamental core SHA1 object handling routines about gitlinks. We can compare trees with gitlinks in them (although we can not actually generate patches for them yet - just raw git diffs), and they show up as commits in "git ls-tree". We also know to compare gitlinks as if they were directories (ie the normal "sort as trees" rules apply). [jc: amended a cut&paste error] Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-10sha1_file.c: learn about index version 2Libravatar Nicolas Pitre1-29/+89
With this patch, packs larger than 4GB are usable, even on a 32-bit machine (at least on Linux). If off_t is not large enough to deal with a large pack then die() is called instead of attempting to use the pack and producing garbage. This was tested with a 8GB pack specially created for the occasion on a 32-bit machine. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-10make overflow test on delta base offset work regardless of variable sizeLibravatar Nicolas Pitre1-1/+1
This patch introduces the MSB() macro to obtain the desired number of most significant bits from a given variable independently of the variable type. It is then used to better implement the overflow test on the OBJ_OFS_DELTA base offset variable with the property of always working correctly regardless of the type/size of that variable. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-10get rid of num_packed_objects()Libravatar Nicolas Pitre1-11/+6
The coming index format change doesn't allow for the number of objects to be determined from the size of the index file directly. Instead, Let's initialize a field in the packed_git structure with the object count when the index is validated since the count is always known at that point. While at it let's reorder some struct packed_git fields to avoid padding due to needed 64-bit alignment for some of them. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-05clean up and optimize nth_packed_object_sha1() usageLibravatar Nicolas Pitre1-5/+4
Let's avoid the open coded pack index reference in pack-object and use nth_packed_object_sha1() instead. This will help encapsulating index format differences in one place. And while at it there is no reason to copy SHA1's over and over while a direct pointer to it in the index will do just fine. Signed-off-by: Nicolas Pitre <nico@cam.org> Acked-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-27sha1_file.c (write_sha1_file): Detect close failureLibravatar Junio C Hamano1-1/+2
This is in the same spirit as earlier fix to write_sha1_from_fd(). Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-27sha1_file.c (write_sha1_from_fd): Detect close failure.Libravatar Jim Meyering1-1/+2
I stumbled across this in the context of the fchmod 0444 patch. At first, I was going to unlink and call error like the two subsequent tests do, but a failed write (above) provokes a "die", so I made this do the same. This is testing for a write failure, after all. Signed-off-by: Jim Meyering <jim@meyering.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-24write_sha1_from_fd() should make new objects read-onlyLibravatar Nicolas Pitre1-0/+1
... like it is done everywhere else. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-24make it more obvious that temporary files are temporary filesLibravatar Nicolas Pitre1-2/+2
When some operations are interrupted (or "die()'d" or crashed) then the partial object/pack/index file may remain around. Make it more obvious in their name that those files are temporary stuff and can be cleaned up if no operation is in progress. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-20Be more careful about zlib return valuesLibravatar Linus Torvalds1-4/+9
When creating a new object, we use "deflate(stream, Z_FINISH)" in a loop until it no longer returns Z_OK, and then we do "deflateEnd()" to finish up business. That should all work, but the fact is, it's not how you're _supposed_ to use the zlib return values properly: - deflate() should never return Z_OK in the first place, except if we need to increase the output buffer size (which we're not doing, and should never need to do, since we pre-allocated a buffer that is supposed to be able to hold the output in full). So the "while()" loop was incorrect: Z_OK doesn't actually mean "ok, continue", it means "ok, allocate more memory for me and continue"! - if we got an error return, we would consider it to be end-of-stream, but it could be some internal zlib error. In short, we should check for Z_STREAM_END explicitly, since that's the only valid return value anyway for the Z_FINISH case. - we never checked deflateEnd() return codes at all. Now, admittedly, none of these issues should ever happen, unless there is some internal bug in zlib. So this patch should make zero difference, but it seems to be the right thing to do. We should probablybe anal and check the return value of "deflateInit()" too! Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-20index-pack: use hash_sha1_file()Libravatar Nicolas Pitre1-2/+2
Use hash_sha1_file() instead of duplicating code to compute object SHA1. While at it make it accept a const pointer. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-19Fix loose object uncompression check.Libravatar Linus Torvalds1-2/+15
The thing is, if the output buffer is empty, we should *still* actually use the zlib routines to *unpack* that empty output buffer. But we had a test that said "only unpack if we still expect more output". So we wouldn't use up all the zlib stream, because we felt that we didn't need it, because we already had all the bytes we wanted. And it was "true": we did have all the output data. We just needed to also eat all the input data! We've had this bug before - thinking that we don't need to inflate() anything because we already had it all.. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-19use a LRU eviction policy for the delta base cacheLibravatar Nicolas Pitre1-8/+31
This provides a smoother degradation in performance when the cache gets trashed due to the delta_base_cache_limit being reached. Limited testing with really small delta_base_cache_limit values appears to confirm this. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-19clean up the delta base cache size a bitLibravatar Nicolas Pitre1-3/+3
Currently there are 3 different ways to deal with the cache size. Let's stick to only one. The compiler is smart enough to produce the exact same code in those cases anyway. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-18Limit the size of the new delta_base_cacheLibravatar Shawn O. Pearce1-4/+26
The new configuration variable core.deltaBaseCacheLimit allows the user to control how much memory they are willing to give to Git for caching base objects of deltas. This is not normally meant to be a user tweakable knob; the "out of the box" settings are meant to be suitable for almost all workloads. We default to 16 MiB under the assumption that the cache is not meant to consume all of the user's available memory, and that the cache's main purpose was to cache trees, for faster path limiters during revision traversal. Since trees tend to be relatively small objects, this relatively small limit should still allow a large number of objects. On the other hand we don't want the cache to start storing 200 different versions of a 200 MiB blob, as this could easily blow the entire address space of a 32 bit process. We evict OBJ_BLOB from the cache first (credit goes to Junio) as we want to favor OBJ_TREE within the cache. These are the objects that have the highest inflate() startup penalty, as they tend to be small and thus don't have that much of a chance to ammortize that penalty over the entire data. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-18Reuse cached data out of delta base cache.Libravatar Nicolas Pitre1-4/+10
A malloc() + memcpy() will always be faster than mmap() + malloc() + inflate(). If the data is already there it is certainly better to copy it straight away. With this patch below I can do 'git log drivers/scsi/ > /dev/null' about 7% faster. I bet it might be even more on those platforms with bad mmap() support. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-18Implement a simple delta_base cacheLibravatar Linus Torvalds1-1/+42
This trivial 256-entry delta_base cache improves performance for some loads by a factor of 2.5 or so. Instead of always re-generating the delta bases (possibly over and over and over again), just cache the last few ones. They often can get re-used. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-18Make trivial wrapper functions around delta base generation and freeingLibravatar Linus Torvalds1-2/+14
This doesn't change any code, it just creates a point for where we'd actually do the caching of delta bases that have been generated. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-16[PATCH] clean up pack index handling a bitLibravatar Nicolas Pitre1-44/+42
Especially with the new index format to come, it is more appropriate to encapsulate more into check_packed_git_idx() and assume less of the index format in struct packed_git. To that effect, the index_base is renamed to index_data with void * type so it is not used directly but other pointers initialized with it. This allows for a couple pointer cast removal, as well as providing a better generic name to grep for when adding support for new index versions or formats. And index_data is declared const too while at it. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-11prepare_packed_git(): sort packs by age and localness.Libravatar Junio C Hamano1-0/+56
When accessing objects, we first look for them in packs that are linked together in the reverse order of discovery. Since younger packs tend to contain more recent objects, which are more likely to be accessed often, and local packs tend to contain objects more relevant to our specific projects, sort the list of packs before starting to access them. In addition, favoring local packs over the ones borrowed from alternates can be a win when alternates are mounted on network file systems. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-10Merge branch 'jc/fsck'Libravatar Junio C Hamano1-8/+19
* jc/fsck: fsck: exit with non-zero status upon errors unpack_sha1_file(): detect corrupt loose object files. fsck: fix broken loose object check.
2007-03-07Cast 64 bit off_t to 32 bit size_tLibravatar Shawn O. Pearce1-17/+23
Some systems have sizeof(off_t) == 8 while sizeof(size_t) == 4. This implies that we are able to access and work on files whose maximum length is around 2^63-1 bytes, but we can only malloc or mmap somewhat less than 2^32-1 bytes of memory. On such a system an implicit conversion of off_t to size_t can cause the size_t to wrap, resulting in unexpected and exciting behavior. Right now we are working around all gcc warnings generated by the -Wshorten-64-to-32 option by passing the off_t through xsize_t(). In the future we should make xsize_t on such problematic platforms detect the wrapping and die if such a file is accessed. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-07Use off_t when we really mean a file offset.Libravatar Shawn O. Pearce1-25/+29
Not all platforms have declared 'unsigned long' to be a 64 bit value, but we want to support a 64 bit packfile (or close enough anyway) in the near future as some projects are getting large enough that their packed size exceeds 4 GiB. By using off_t, the POSIX type that is declared to mean an offset within a file, we support whatever maximum file size the underlying operating system will handle. For most modern systems this is up around 2^60 or higher. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>