aboutsummaryrefslogtreecommitdiff
path: root/sha1_file.c
Commit message (Collapse)AuthorAge
* War on whitespaceJunio C Hamano2007-06-07
| | | | | | | | | 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>
* Merge branch 'sp/pack'Junio C Hamano2007-06-02
|\ | | | | | | | | | | | | | | | | | | | | | | * 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
| * Style nit - don't put space after function namesShawn O. Pearce2007-05-29
| | | | | | | | | | | | | | | | | | 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>
| * Micro-optimize prepare_alt_odbShawn O. Pearce2007-05-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * Lazily open pack index files on demandShawn O. Pearce2007-05-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge branch 'maint'Junio C Hamano2007-05-31
|\ \ | | | | | | | | | | | | | | | | | | | | | * 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
| * \ Merge branch 'maint-1.5.1' into maintJunio C Hamano2007-05-31
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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
| | * | fix signed range problems with hex conversionsLinus Torvalds2007-05-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | | always start looking up objects in the last used pack firstNicolas Pitre2007-05-30
| |_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | Merge branch 'np/pack'Junio C Hamano2007-05-20
|\ \ \ | |/ / |/| | | | | | | | | | | | | | * 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
| * | deprecate the new loose object header formatNicolas Pitre2007-05-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | Ensure return value from xread() is always stored into an ssize_tJohan Herland2007-05-15
|/ / | | | | | | | | | | | | | | | | 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>
* | Merge branch 'maint'Junio C Hamano2007-04-25
|\ \ | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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
| * Actually handle some-low memory conditionsShawn O. Pearce2007-04-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge branch 'jc/attr'Junio C Hamano2007-04-21
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * '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 '-'. ...
| * | Simplify calling of CR/LF conversion routinesAlex Riesen2007-04-20
| | | | | | | | | | | | | | | Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
* | | Merge branch 'lt/gitlink'Junio C Hamano2007-04-21
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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
| * | | Teach core object handling functions about gitlinksLinus Torvalds2007-04-10
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | add get_size_from_delta()Nicolas Pitre2007-04-16
| | | | | | | | | | | | | | | | | | | | | | | | ... 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>
* | | sha1_file.c: learn about index version 2Nicolas Pitre2007-04-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | make overflow test on delta base offset work regardless of variable sizeNicolas Pitre2007-04-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | get rid of num_packed_objects()Nicolas Pitre2007-04-10
|/ / | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | clean up and optimize nth_packed_object_sha1() usageNicolas Pitre2007-04-05
|/ | | | | | | | | | | | | 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>
* sha1_file.c (write_sha1_file): Detect close failureJunio C Hamano2007-03-27
| | | | | | This is in the same spirit as earlier fix to write_sha1_from_fd(). Signed-off-by: Junio C Hamano <junkio@cox.net>
* sha1_file.c (write_sha1_from_fd): Detect close failure.Jim Meyering2007-03-27
| | | | | | | | | | 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>
* write_sha1_from_fd() should make new objects read-onlyNicolas Pitre2007-03-24
| | | | | | | ... like it is done everywhere else. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* make it more obvious that temporary files are temporary filesNicolas Pitre2007-03-24
| | | | | | | | | | 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>
* Be more careful about zlib return valuesLinus Torvalds2007-03-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* index-pack: use hash_sha1_file()Nicolas Pitre2007-03-20
| | | | | | | | 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>
* Fix loose object uncompression check.Linus Torvalds2007-03-19
| | | | | | | | | | | | | | | | | | 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>
* use a LRU eviction policy for the delta base cacheNicolas Pitre2007-03-19
| | | | | | | | | | 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>
* clean up the delta base cache size a bitNicolas Pitre2007-03-19
| | | | | | | | | 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>
* Limit the size of the new delta_base_cacheShawn O. Pearce2007-03-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Reuse cached data out of delta base cache.Nicolas Pitre2007-03-18
| | | | | | | | | | | | | 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>
* Implement a simple delta_base cacheLinus Torvalds2007-03-18
| | | | | | | | | | | 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>
* Make trivial wrapper functions around delta base generation and freeingLinus Torvalds2007-03-18
| | | | | | | | 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>
* [PATCH] clean up pack index handling a bitNicolas Pitre2007-03-16
| | | | | | | | | | | | | | | | | 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>
* prepare_packed_git(): sort packs by age and localness.Junio C Hamano2007-03-11
| | | | | | | | | | | | | | 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>
* Merge branch 'jc/fsck'Junio C Hamano2007-03-10
|\ | | | | | | | | | | | | * jc/fsck: fsck: exit with non-zero status upon errors unpack_sha1_file(): detect corrupt loose object files. fsck: fix broken loose object check.
| * unpack_sha1_file(): detect corrupt loose object files.Junio C Hamano2007-03-05
| | | | | | | | | | | | | | | | | | | | | | | | We did not detect broken loose object files, either when underlying inflate() signalled the breakage, nor inflate() finished and we had garbage trailing at the end. We do better now. We also make unpack_sha1_file() a static function to sha1_file.c, since it is not used by anybody outside. Signed-off-by: Junio C Hamano <junkio@cox.net>
* | Cast 64 bit off_t to 32 bit size_tShawn O. Pearce2007-03-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Use off_t when we really mean a file offset.Shawn O. Pearce2007-03-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Use uint32_t for all packed object counts.Shawn O. Pearce2007-03-07
| | | | | | | | | | | | | | | | | | | | | | | | | | As we permit up to 2^32-1 objects in a single packfile we cannot use a signed int to represent the object offset within a packfile, after 2^31-1 objects we will start seeing negative indexes and error out or compute bad addresses within the mmap'd index. This is a minor cleanup that does not introduce any significant logic changes. It is roach free. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* | General const correctness fixesShawn O. Pearce2007-03-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We shouldn't attempt to assign constant strings into char*, as the string is not writable at runtime. Likewise we should always be treating unsigned values as unsigned values, not as signed values. Most of these are very straightforward. The only exception is the (unnecessary) xstrdup/free in builtin-branch.c for the detached head case. Since this is a user-level interactive type program and that particular code path is executed no more than once, I feel that the extra xstrdup call is well worth the easy elimination of this warning. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* | Fix mmap leak caused by reading bad indexes.Shawn O. Pearce2007-03-07
| | | | | | | | | | | | | | | | | | | | If an index is corrupt, or is simply too new for us to understand, we were leaking the mmap that held the entire content of the index. This could be a considerable size on large projects, given that the index is at least 24 bytes * nr_objects. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* | Display the null SHA-1 as the base for an OBJ_OFS_DELTA.Shawn O. Pearce2007-03-07
|/ | | | | | | | | | | Because we are currently cheating and never supplying the delta base for an OBJ_OFS_DELTA we get a random SHA-1 in the delta base field. Instead lets clear the hash out so its at least all 0's. This is somewhat more obvious that something fishy is going on, like we don't actually have the SHA-1 of the base handy. :) Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* index_fd(): convert blob only if it is a regular file.Junio C Hamano2007-02-28
| | | | Signed-off-by: Junio C Hamano <junkio@cox.net>
* index_fd(): pass optional path parameter as hint for blob conversionJunio C Hamano2007-02-28
| | | | Signed-off-by: Junio C Hamano <junkio@cox.net>
* index_fd(): use enum object_type instead of type name string.Junio C Hamano2007-02-28
| | | | Signed-off-by: Junio C Hamano <junkio@cox.net>
* convert object type handling from a string to a numberNicolas Pitre2007-02-27
| | | | | | | | | | | | | | | We currently have two parallel notation for dealing with object types in the code: a string and a numerical value. One of them is obviously redundent, and the most used one requires more stack space and a bunch of strcmp() all over the place. This is an initial step for the removal of the version using a char array found in object reading code paths. The patch is unfortunately large but there is no sane way to split it in smaller parts without breaking the system. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>