- 21 3月, 2007 2 次提交
-
-
由 Linus Torvalds 提交于
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: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Nicolas Pitre 提交于
Use hash_sha1_file() instead of duplicating code to compute object SHA1. While at it make it accept a const pointer. Signed-off-by: NNicolas Pitre <nico@cam.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 20 3月, 2007 3 次提交
-
-
由 Linus Torvalds 提交于
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: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Nicolas Pitre 提交于
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: NNicolas Pitre <nico@cam.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Nicolas Pitre 提交于
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: NNicolas Pitre <nico@cam.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 19 3月, 2007 4 次提交
-
-
由 Shawn O. Pearce 提交于
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: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Nicolas Pitre 提交于
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: NNicolas Pitre <nico@cam.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Linus Torvalds 提交于
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: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Linus Torvalds 提交于
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: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 17 3月, 2007 1 次提交
-
-
由 Nicolas Pitre 提交于
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: NNicolas Pitre <nico@cam.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 11 3月, 2007 1 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <junkio@cox.net>
-
- 08 3月, 2007 6 次提交
-
-
由 Shawn O. Pearce 提交于
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: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Shawn O. Pearce 提交于
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: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Shawn O. Pearce 提交于
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: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Shawn O. Pearce 提交于
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: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Shawn O. Pearce 提交于
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: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Shawn O. Pearce 提交于
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: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 05 3月, 2007 1 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <junkio@cox.net>
-
- 01 3月, 2007 3 次提交
-
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 27 2月, 2007 5 次提交
-
-
由 Nicolas Pitre 提交于
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: NNicolas Pitre <nico@cam.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Nicolas Pitre 提交于
Sometime typename() is used, sometimes type_names[] is accessed directly. Let's enforce typename() all the time which allows for validating the type. Also let's add a function to go from a name to a type and use it instead of manual memcpy() when appropriate. Signed-off-by: NNicolas Pitre <nico@cam.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Nicolas Pitre 提交于
Signed-off-by: NNicolas Pitre <nico@cam.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Nicolas Pitre 提交于
First there are too many offsets there and it is getting confusing. So 'offset' is now 'curpos' to distinguish from other offsets like 'obj_offset'. Then structures like x = foo(x, &y) are now done as y = foo(&x). It looks more natural that the result y be returned directly and x be passed as reference to be updated in place. This has the effect of reducing some line length and removing a few, needing a bit less stack space, and it even reduces the compiled code size. Signed-off-by: NNicolas Pitre <nico@cam.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Nicolas Pitre 提交于
Let's have hdr be a simple char pointer/array when possible, and let's reduce its storage to 32 bytes. Especially for sha1_loose_object_info() where 128 bytes is way excessive and wastes extra CPU cycles inflating. The object type is already restricted to 10 bytes in parse_sha1_header() and the size, even if it is 64 bits, will fit in 20 decimal numbers. So 32 bytes is plenty. Signed-off-by: NNicolas Pitre <nico@cam.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 16 2月, 2007 1 次提交
-
-
由 Junio C Hamano 提交于
We stashed away objects that we pretend to have, but did not save the actual data. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 15 2月, 2007 2 次提交
-
-
由 Alexandre Julliard 提交于
This ensures that a given area is mapped at most twice, and greatly reduces the virtual address space usage. Signed-off-by: NAlexandre Julliard <julliard@winehq.org> Acked-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Linus Torvalds 提交于
It currently does NOT know about file attributes, so it does its conversion purely based on content. Maybe that is more in the "git philosophy" anyway, since content is king, but I think we should try to do the file attributes to turn it off on demand. Anyway, BY DEFAULT it is off regardless, because it requires a [core] AutoCRLF = true in your config file to be enabled. We could make that the default for Windows, of course, the same way we do some other things (filemode etc). But you can actually enable it on UNIX, and it will cause: - "git update-index" will write blobs without CRLF - "git diff" will diff working tree files without CRLF - "git checkout" will write files to the working tree _with_ CRLF and things work fine. Funnily, it actually shows an odd file in git itself: git clone -n git test-crlf cd test-crlf git config core.autocrlf true git checkout git diff shows a diff for "Documentation/docbook-xsl.css". Why? Because we have actually checked in that file *with* CRLF! So when "core.autocrlf" is true, we'll always generate a *different* hash for it in the index, because the index hash will be for the content _without_ CRLF. Is this complete? I dunno. It seems to work for me. It doesn't use the filename at all right now, and that's probably a deficiency (we could certainly make the "is_binary()" heuristics also take standard filename heuristics into account). I don't pass in the filename at all for the "index_fd()" case (git-update-index), so that would need to be passed around, but this actually works fine. NOTE NOTE NOTE! The "is_binary()" heuristics are totally made-up by yours truly. I will not guarantee that they work at all reasonable. Caveat emptor. But it _is_ simple, and it _is_ safe, since it's all off by default. The patch is pretty simple - the biggest part is the new "convert.c" file, but even that is really just basic stuff that anybody can write in "Teaching C 101" as a final project for their first class in programming. Not to say that it's bug-free, of course - but at least we're not talking about rocket surgery here. Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 14 2月, 2007 1 次提交
-
-
由 Linus Torvalds 提交于
Here's a patch that I think we can merge right now. There may be other places that need this, but this at least points out the three places that read/write working tree files for git update-index, checkout and diff respectively. That should cover a lot of it [jc: git-apply uses an entirely different codepath both for reading and writing]. Some day we can actually implement it. In the meantime, this points out a place for people to start. We *can* even start with a really simple "we do CRLF conversion automatically, regardless of filename" kind of approach, that just look at the data (all three cases have the _full_ file data already in memory) and says "ok, this is text, so let's convert to/from DOS format directly". THAT somebody can write in ten minutes, and it would already make git much nicer on a DOS/Windows platform, I suspect. And it would be totally zero-cost if you just make it a config option (but please make it dynamic with the _default_ just being 0/1 depending on whether it's UNIX/Windows, just so that UNIX people can _test_ it easily). Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 06 2月, 2007 1 次提交
-
-
由 Junio C Hamano 提交于
The new interface allows an application to temporarily hash a small number of objects and pretend that they are available in the object store without actually writing them. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 04 2月, 2007 1 次提交
-
-
由 Pavel Roskin 提交于
Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 03 2月, 2007 1 次提交
-
-
由 Shawn O. Pearce 提交于
If open_packed_git failed it may have been because the packfile actually exists and is readable, but some sort of verification did not pass. In this case open_packed_git left pack_fd filled in, as the file descriptor is valid. We don't want to leak the file descriptor, nor do we want to allow someone in the future to use this packed_git. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 02 2月, 2007 4 次提交
-
-
由 Shawn O. Pearce 提交于
Matthias Lederhofer identified a race condition where a Git reader process was able to locate an object in a packed_git index, but was then preempted while a `git repack -a -d` ran and completed. By the time the reader was able to seek in the packfile to get the object data, the packfile no longer existed on disk. In this particular case the reader process did not attempt to open the packfile before it was deleted, so it did not already have the pack_fd field popuplated. With the packfile itself gone, there was no way for the reader to open it and fetch the data. I'm fixing the race condition by teaching find_pack_entry to ignore a packed_git whose packfile is not currently open and which cannot be opened. If none of the currently known packs can supply the object, we will return 0 and the caller will decide the object is not available. If this is the first attempt at finding an object, the caller will reprepare_packed_git and try again. If it was the second attempt, the caller will typically return NULL back, and an error message about a missing object will be reported. This patch does not address the situation of a reader which is being starved out by a tight sequence of `git repack -a -d` runs. In this particular case the reader will try twice, probably fail both times, and declare the object in question cannot be found. As it is highly unlikely that a real world `git repack -a -d` can complete faster than a reader can open a packfile, so I don't think this is a huge concern. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Shawn O. Pearce 提交于
Because I want to reuse open_packed_git in a context where I don't want the process to die if the packfile in question is bogus, I'm changing its behavior to return error("...") rather than die("...") when it detects something is wrong with the packfile it was given. Right now we still must die out of use_pack should open_packed_git fail, as none of use_pack's callers are prepared to handle a failure from that function. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Shawn O. Pearce 提交于
After staring at the comment and the associated for loop, I realized the comment was completely bogus. The section of code its talking about is trying to avoid duplicate mapping of the same packfile. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Shawn O. Pearce 提交于
There is little point in having the linked list insertion code appearing in install_packed_git, and then again just 30 lines further down in the same file. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 25 1月, 2007 1 次提交
-
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 23 1月, 2007 1 次提交
-
-
由 Peter Eriksen 提交于
We used to call find_pack_entry() twice from read_sha1_file() in order to avoid printing an error message, when the object did not exist. This is fixed by moving the call to error() to the only place it really could be called. Signed-off-by: NPeter Eriksen <s022018@student.dtu.dk> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 19 1月, 2007 1 次提交
-
-
由 Junio C Hamano 提交于
This attempts to finish what Simon started in the previous commit. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-