- 30 12月, 2006 3 次提交
-
-
由 Shawn O. Pearce 提交于
The idea behind the sliding mmap window pack reader implementation is to have multiple mmap regions active against the same pack file, thereby allowing the process to mmap in only the active/hot sections of the pack and reduce overall virtual address space usage. To implement this we need to refactor the mmap related data (pack_base, pack_use_cnt) out of struct packed_git and move them into a new struct pack_window. We are refactoring the code to support a single struct pack_window per packfile, thereby emulating the prior behavior of mmap'ing the entire pack file. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Shawn O. Pearce 提交于
Rather than hardcoding the maximum number of bytes which can be mmapped from pack files we should make this value configurable, allowing the end user to increase or decrease this limit on a per-repository basis depending on the size of the repository and the capabilities of their operating system. In general users should not need to manually tune such a low-level setting within the core code, but being able to artifically limit the number of bytes which we can mmap at once from pack files will make it easier to craft test cases for the new mmap sliding window implementation. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Shawn O. Pearce 提交于
The unpack_entry_gently function currently has only two callers: the delta base resolution in sha1_file.c and the main loop of pack-check.c. Both of these must change to using unpack_entry directly when we implement sliding window mmap logic, so I'm doing it earlier to help break down the change set. This may cause a slight performance decrease for delta base resolution as well as for pack-check.c's verify_packfile(), as the pack use counter will be incremented and decremented for every object that is unpacked. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 21 12月, 2006 1 次提交
-
-
由 Nicolas Pitre 提交于
If ever new object types are added for future extensions then better have current git version report them as "unknown" instead of "corrupted". Signed-off-by: NNicolas Pitre <nico@cam.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 28 11月, 2006 1 次提交
-
-
由 Johannes Schindelin 提交于
We used to try loose objects first with sha1_object_info(), but packed objects first with read_sha1_file(). Now, prefer packed objects over loose ones with sha1_object_info(), too. Usually the old behaviour would pose no problem, but when you tried to fix a fscked up repository by inserting a known-good pack, git cat-file $(git cat-file -t <sha1>) <sha1> could fail, even when git cat-file blob <sha1> would _not_ fail. Worse, a repack would fail, too. Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 10 11月, 2006 1 次提交
-
-
由 Petr Baudis 提交于
Currently the error e.g. when pushing to a read-only repository is quite confusing, this attempts to clean it up, unifies error reporting between various object writers and uses error() on couple more places. Signed-off-by: NPetr Baudis <pasky@suse.cz> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 03 11月, 2006 2 次提交
-
-
由 Shawn Pearce 提交于
Since keeping a pushed pack or exploding it into loose objects should be a local repository decision this teaches receive-pack to decide if it should call unpack-objects or index-pack --stdin --fix-thin based on the setting of receive.unpackLimit and the number of objects contained in the received pack. If the number of objects (hdr_entries) in the received pack is below the value of receive.unpackLimit (which is 5000 by default) then we unpack-objects as we have in the past. If the hdr_entries >= receive.unpackLimit then we call index-pack and ask it to include our pid and hostname in the .keep file to make it easier to identify why a given pack has been kept in the repository. Currently this leaves every received pack as a kept pack. We really don't want that as received packs will tend to be small. Instead we want to delete the .keep file automatically after all refs have been updated. That is being left as room for future improvement. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Johannes Schindelin 提交于
-
- 01 11月, 2006 1 次提交
-
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 31 10月, 2006 1 次提交
-
-
由 Junio C Hamano 提交于
This reverts commit c7740a94. There should be a way to make this controllable from the receiver end.
-
- 30 10月, 2006 1 次提交
-
-
由 Shawn Pearce 提交于
This allows us to pass just the file name of a pack rather than the complete path when we want pack-objects to consider its contents as though they were loose objects. This can be helpful if $GIT_OBJECT_DIRECTORY contains shell metacharacters which make it cumbersome to pass complete paths safely in a shell script. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 29 10月, 2006 1 次提交
-
-
由 Junio C Hamano 提交于
This adds "keep-pack" extension to send-pack vs receive pack protocol, and makes the receiver invoke "index-pack --stdin --fix-thin". With this, you can ask send-pack not to explode the result into loose objects on the receiving end. I've patched has_sha1_file() to re-check for added packs just like is done in read_sha1_file() for now, but I think the static "re-prepare" interface for packs was a mistake. Creation of a new pack inside a process that needs to read objects in them back ought to be a rare event, so we are better off making the callers (such as receive-pack that calls "index-pack --stdin --fix-thin") explicitly call re-prepare. That way we do not have to penalize ordinary users of read_sha1_file() and has_sha1_file(). We would need to fix this someday. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 19 10月, 2006 1 次提交
-
-
由 Nicolas Pitre 提交于
Supposing that both the base and result sizes were both full size 64-bit values, their encoding would occupy only 9.2 bytes each. Therefore inflating 64 bytes is way overkill. Limit it to 20 bytes instead which should be plenty enough for a couple years to come. Signed-off-by: NNicolas Pitre <nico@cam.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 16 10月, 2006 2 次提交
-
-
由 Rene Scharfe 提交于
Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Rene Scharfe 提交于
Move file name generation from write_sha1_file_prepare() to the one caller that cares and make it a void function. Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 15 10月, 2006 2 次提交
-
-
由 Rene Scharfe 提交于
There are no callers of write_sha1_file_prepare() left outside of sha1_file.c, so make it static. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Rene Scharfe 提交于
Most callers of write_sha1_file_prepare() are only interested in the resulting hash but don't care about the returned file name or the header. This patch adds a simple wrapper named hash_sha1_file() which does just that, and converts potential callers. Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 27 9月, 2006 2 次提交
-
-
由 Nicolas Pitre 提交于
This is the missing part to git-pack-objects allowing it to reuse delta data to/from any of the two delta types. It can reuse delta from any type, and it outputs base offsets when --allow-delta-base-offset is provided and the base is also included in the pack. Otherwise it outputs base sha1 references just like it always did. Signed-off-by: NNicolas Pitre <nico@cam.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Nicolas Pitre 提交于
This adds a new object, namely OBJ_OFS_DELTA, renames OBJ_DELTA to OBJ_REF_DELTA to better make the distinction between those two delta objects, and adds support for the handling of those new delta objects in sha1_file.c only. The OBJ_OFS_DELTA contains a relative offset from the delta object's position in a pack instead of the 20-byte SHA1 reference to identify the base object. Since the base is likely to be not so far away, the relative offset is more likely to have a smaller encoding on average than an absolute offset. And for those delta objects the base must always be stored first because there is no way to know the distance of later objects when streaming a pack. Hence this relative offset is always meant to be negative. The offset encoding is slightly denser than the one used for object size -- credits to <linux@horizon.com> (whoever this is) for bringing it to my attention. This allows for pack size reduction between 3.2% (Linux-2.6) to over 5% (linux-historic). Runtime pack access should be faster too since delta replay does skip a search in the pack index for each delta in a chain. Signed-off-by: NNicolas Pitre <nico@cam.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 23 9月, 2006 1 次提交
-
-
由 Nicolas Pitre 提交于
Those cleanups are mainly to set the table for the support of deltas with base objects referenced by offsets instead of sha1. This means that many pack lookup functions are converted to take a pack/offset tuple instead of a sha1. This eliminates many struct pack_entry usages since this structure carried redundent information in many cases, and it increased stack footprint needlessly for a couple recursively called functions that used to declare a local copy of it for every recursion loop. In the process, packed_object_info_detail() has been reorganized as well so to look much saner and more amenable to deltas with offset support. Finally the appropriate adjustments have been made to functions that depend on the above changes. But there is no functionality changes yet simply some code refactoring at this point. Signed-off-by: NNicolas Pitre <nico@cam.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 21 9月, 2006 1 次提交
-
-
由 Junio C Hamano 提交于
builtin-mailinfo.c has its own hexval implementaiton but it can share the table-lookup one recently implemented in sha1_file.c Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 10 9月, 2006 1 次提交
-
-
由 Junio C Hamano 提交于
The function appeared high on a gprof output for a rev-list run of a non-trivial size, and it was an obvious low-hanging fruit. The code is from Linus. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 07 9月, 2006 1 次提交
-
-
由 Junio C Hamano 提交于
Incremental repack without -a essentially boils down to: rev-list --objects --unpacked --all | pack-objects $new_pack which picks up all loose objects that are still live and creates a new pack. This implements --unpacked=<existing pack> option to tell the revision walking machinery to pretend as if objects in such a pack are unpacked for the purpose of object listing. With this, we could say: rev-list --objects --unpacked=$active_pack --all | pack-objects $new_pack instead, to mean "all live loose objects but pretend as if objects that are in this pack are also unpacked". The newly created pack would be perfect for updating $active_pack by replacing it. Since pack-objects now knows how to do the rev-list's work itself internally, you can also write the above example by: pack-objects --unpacked=$active_pack --all $new_pack </dev/null Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 04 9月, 2006 1 次提交
-
-
由 Junio C Hamano 提交于
When copying from an existing pack and when copying from a loose object with new style header, the code makes sure that the piece we are going to copy out inflates well and inflate() consumes the data in full while doing so. The check to see if the xdelta really apply is quite expensive as you described, because you would need to have the image of the base object which can be represented as a delta against something else. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 03 9月, 2006 1 次提交
-
-
由 Junio C Hamano 提交于
This reverts commit 0270083d.
-
- 02 9月, 2006 2 次提交
-
-
由 Shawn Pearce 提交于
Like xmalloc and xrealloc xstrdup dies with a useful message if the native strdup() implementation returns NULL rather than a valid pointer. I just tried to use xstrdup in new code and found it to be missing. However I expected it to be present as xmalloc and xrealloc are already commonly used throughout the code. [jc: removed the part that deals with last_XXX, which I am finding more and more dubious these days.] Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
Also while we are at it, remove redundant typename[] array from unpack_sha1_header. The only reason it is different from the type_names[] array in object.c module is that this code cares about the subset of object types that are valid in a loose object, so prepare a separate array of boolean that tells us which types are valid, and share the name translation with the others. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 01 9月, 2006 2 次提交
-
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Jonas Fonseca 提交于
Signed-off-by: NJonas Fonseca <fonseca@diku.dk> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 27 8月, 2006 6 次提交
-
-
由 Jonas Fonseca 提交于
Change places that use realloc, without a proper error path, to instead use xrealloc. Drop an erroneous error path in the daemon code that used errno in the die message in favour of the simpler xrealloc. Signed-off-by: NJonas Fonseca <fonseca@diku.dk> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Shawn Pearce 提交于
Change unpack_entry_gently and its helper functions to use offsets rather than addresses and left counts to supply pack position information. In most cases this makes the code easier to follow, and it reduces the number of local variables in a few functions. It also better prepares this code for mapping partial segments of packs and altering what regions of a pack are mapped while unpacking an entry. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Shawn Pearce 提交于
If we're always incrementing both the offset and the pointer we aren't gaining anything by keeping both. Instead just use the offset since that's what we were given and what we are expected to return. Also using offset is likely to make it easier to remap the pack in the future should partial mapping of very large packs get implemented. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Shawn Pearce 提交于
[PATCH 3/5] Cleanup unpack_entry_gently and friends to use type_name array. This change allows combining all of the non-delta entries into a single case, as well as to remove an unnecessary local variable in unpack_entry_gently. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Shawn Pearce 提交于
[PATCH 2/5] Reuse compression code in unpack_compressed_entry. This cleans up the code by reusing a perfectly good decompression implementation at the expense of 1 extra byte of memory allocated in temporary memory while the delta is being decompressed and applied to the base. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Shawn Pearce 提交于
This function was moved above unpack_delta_entry so we can call it from within unpack_delta_entry without a forward declaration. This change looks worse than it is. Its really just a relocation of unpack_non_delta_entry to earlier in the file and renaming the function to unpack_compressed_entry. No other changes were made. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 24 8月, 2006 1 次提交
-
-
由 Shawn Pearce 提交于
This abstracts away the size of the hash values when copying them from memory location to memory location, much as the introduction of hashcmp abstracted away hash value comparsion. A few call sites were using char* rather than unsigned char* so I added the cast rather than open hashcpy to be void*. This is a reasonable tradeoff as most call sites already use unsigned char* and the existing hashcmp is also declared to be unsigned char*. [jc: Splitted the patch to "master" part, to be followed by a patch for merge-recursive.c which is not in "master" yet. Fixed the cast in the latter hunk to combine-diff.c which was wrong in the original. Also converted ones left-over in combine-diff.c, diff-lib.c and upload-pack.c ] Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 22 8月, 2006 2 次提交
-
-
由 Shawn Pearce 提交于
This declaration probably used to be necessary but the code has been refactored since to use unpack_entry_gently instead. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Shawn Pearce 提交于
If the pack format were to ever change or be extended in the future there is no assurance that just because the pack file lives in objects/pack and doesn't end in .idx that we can read and decompress its contents properly. If we encounter what we think is a pack file and it isn't or we don't recognize its version then die and suggest to the user that they upgrade to a newer version of GIT which can handle that pack file. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 18 8月, 2006 1 次提交
-
-
由 David Rientjes 提交于
Introduces global inline: hashcmp(const unsigned char *sha1, const unsigned char *sha2) Uses memcmp for comparison and returns the result based on the length of the hash name (a future runtime decision). Acked-by: NAlex Riesen <raa.lkml@gmail.com> Signed-off-by: NDavid Rientjes <rientjes@google.com> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 16 8月, 2006 1 次提交
-
-
由 David Rientjes 提交于
[jc: I needed to hand merge the changes to the updated codebase, so the result needs to be checked.] Signed-off-by: NDavid Rientjes <rientjes@google.com> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-