- 02 Nov, 2016 1 commit
-
-
In `pack_entry_find_offset`, we try to find the offset of a certain object in the pack file. To do so, we first assert if the packfile has already been opened and open it if not. Opening the packfile is guarded with a mutex, so concurrent access to this is in fact safe. What is not thread-safe though is our calculation of offsets inside the packfile. Assume two threads calling `pack_entry_find_offset` at the same time. We first calculate the offset and index location and only then determine if the pack has already been opened. If so, we re-calculate the offset and index address. Now the case for two threads: thread 1 first calculates the addresses and is subsequently suspended. The second thread will now call `pack_index_open` and initialize the pack file, calculating its addresses correctly. When the first thread is resumed now, he'll see that the pack file has already been initialized and will happily proceed with the addresses it has already calculated before the check. As the pack file was not initialized before, these addresses are bogus. Fix the issue by only calculating the addresses after having checked if the pack file is open.
Patrick Steinhardt committed
-
- 26 May, 2016 1 commit
-
-
Move the delta application functions into `delta.c`, next to the similar delta creation functions. Make the `git__delta_apply` functions adhere to other naming and parameter style within the library.
Edward Thomson committed
-
- 02 May, 2016 1 commit
-
-
When we read the header, we want to know the size and type of the object. We're currently inflating the full delta in order to read the first few bytes. This can mean hundreds of kB needlessly inflated for large objects. Instead use a packfile stream to read just enough so we can read the two varints in the header and avoid inflating most of the delta.
Carlos Martín Nieto committed
-
- 07 Mar, 2016 1 commit
-
-
When looking up an abbreviated oid, show the actual (abbreviated) oid the caller passed instead of a full (but ambiguously truncated) oid.
Edward Thomson committed
-
- 25 Feb, 2016 2 commits
-
-
Carlos Martín Nieto committed
-
A corrupt index might have data that tells us to go look past the end of the file for data. Catch these cases and return an appropriate error message.
Carlos Martín Nieto committed
-
- 09 Feb, 2016 1 commit
-
-
The function `git_packfile_stream_open` tries to free the passed in stream when an error occurs. The only call site is `git_indexer_append`, though, which passes in the address of a stream struct which has not been allocated on the heap. Fix the issue by simply removing the call to free. In case of an error we did not allocate any memory yet and otherwise it should be the caller's responsibility to manage it's object's lifetime.
Patrick Steinhardt committed
-
- 13 Jan, 2016 2 commits
- 31 Jul, 2015 1 commit
-
-
Without this change, compiling with gcc and pedantic generates warning: ISO C does not allow extra ‘;’ outside of a function.
Stefan Widgren committed
-
- 10 Jun, 2015 1 commit
-
-
The way we currently do it depends on the subtlety of strlen vs sizeof and the fact that .pack is one longer than .idx. Let's use a git_buf so we can express the manipulation we want much more clearly.
Carlos Martín Nieto committed
-
- 22 May, 2015 1 commit
-
-
When creating an index, know that we do not have an index for our own packfile, preventing some unnecessary file opens and error reporting.
Edward Thomson committed
-
- 11 Mar, 2015 1 commit
-
-
Keep the definitions in the headers, while putting the declarations in the C files. Putting the function definitions in headers causes them to be duplicated if you include two headers with them.
Carlos Martín Nieto committed
-
- 15 Feb, 2015 1 commit
-
-
Increment refcount of newly added cache entries just like existing entries looked up from the cache. Otherwise the new entry can be evicted from the cache and destroyed while it's still in use.
Jason Haslam committed
-
- 13 Feb, 2015 2 commits
-
-
Make our overflow checking look more like gcc and clang's, so that we can substitute it out with the compiler instrinsics on platforms that support it. This means dropping the ability to pass `NULL` as an out parameter. As a result, the macros also get updated to reflect this as well.
Edward Thomson committed -
Introduce some helper macros to test integer overflow from arithmetic and set error message appropriately.
Edward Thomson committed
-
- 29 Dec, 2014 1 commit
-
-
Jacques Germishuys committed
-
- 21 Nov, 2014 1 commit
-
-
Ravindra Patel committed
-
- 27 Oct, 2014 1 commit
-
-
Pierre-Olivier Latour committed
-
- 26 Sep, 2014 1 commit
-
-
Jacques Germishuys committed
-
- 02 Sep, 2014 1 commit
-
-
Arkady Shapkin committed
-
- 26 Aug, 2014 1 commit
-
-
The callers of git_packfile_unpack() expect the obj_offset argument to be set to the beginning of the next object. We were mistakenly returning the the offset of the object's data, which causes the CRC function to try to use the wrong offset. Set obj_offset to curpos instead of elem->offset to point to the next element and bring back expected behaviour.
Carlos Martín Nieto committed
-
- 25 Jun, 2014 1 commit
-
-
If we fail to insert the packfile in the map, make sure to free it. This makes the free function only attempt to remove its mwindows from the global list if we have opened the packfile to avoid accessing the list unlocked.
Carlos Martín Nieto committed
-
- 23 Jun, 2014 1 commit
-
-
Opening the same repository multiple times will currently open the same file multiple times, as well as map the same region of the file multiple times. This is not necessary, as the packfile data is immutable. Instead of opening and closing packfiles directly, introduce an indirection and allocate packfiles globally. This does mean locking on each packfile open, but we already use this lock for the global mwindow list so it doesn't introduce a new contention point.
Carlos Martín Nieto committed
-
- 15 May, 2014 1 commit
-
-
When running multithreaded, it is not enough to check for the offmap allocation. Move the call to cache_init() to packfile allocation so we can be sure it is always allocated free of races. This fixes #2355.
Carlos Martín Nieto committed
-
- 13 May, 2014 3 commits
-
-
The base object is a good cache candidate, so we shouldn't forget to add it to the cache.
Carlos Martín Nieto committed -
This avoid allocating the array on the heap for relatively small chains. The expected performance increase is sadly not really noticeable.
Carlos Martín Nieto committed -
Instead of going through a special entry in the chain, let's pass it as an output parameter.
Carlos Martín Nieto committed
-
- 09 May, 2014 7 commits
-
-
The switch makes the loop somewhat unwieldy. Let's assume it's fine and perform the check when we're accessing the data. This makes our code look a lot more like git's.
Carlos Martín Nieto committed -
Dependency chains are often large and require a few reallocations. Allocate a 64-element chain before doing anything else to avoid allocations during the loop. This value comes from the stack-allocated one git uses. We still allocate this on the heap, but it does help performance a little bit.
Carlos Martín Nieto committed -
Carlos Martín Nieto committed
-
Bring back the use of the delta base cache for unpacking objects. When generating the delta chain, we stop when we find a delta base in the pack's cache and use that as the starting point.
Carlos Martín Nieto committed -
We currently make use of recursive function calls to unpack an object, resolving the deltas as we come back down the chain. This means that we have unbounded stack growth as we look up objects in a pack. This is now done in two steps: first we figure out what the dependency chain is by looking up the delta bases until we reach a non-delta object, pushing the information we need onto a stack and then we pop from that stack and apply the deltas until there are no more left. This version of the code does not make use of the delta base cache so it is slower than what's in the mainline. A later commit will reintroduce it.
Carlos Martín Nieto committed -
Repeating this error message makes it harder to find out where we actually are finding the error, and they don't really describe what we're trying to do.
Carlos Martín Nieto committed -
Carlos Martín Nieto committed
-
- 23 Jan, 2014 1 commit
-
-
Linquize committed
-
- 11 Dec, 2013 4 commits
-
-
Russell Belfer committed
-
I find this easier to read...
Russell Belfer committed -
This changes the behavior of callbacks so that the callback error code is not converted into GIT_EUSER and instead we propagate the return value through to the caller. Instead of using the giterr_capture and giterr_restore functions, we now rely on all functions to pass back the return value from a callback. To avoid having a return value with no error message, the user can call the public giterr_set_str or some such function to set an error message. There is a new helper 'giterr_set_callback' that functions can invoke after making a callback which ensures that some error message was set in case the callback did not set one. In places where the sign of the callback return value is meaningful (e.g. positive to skip, negative to abort), only the negative values are returned back to the caller, obviously, since the other values allow for continuing the loop. The hardest parts of this were in the checkout code where positive return values were overloaded as meaningful values for checkout. I fixed this by adding an output parameter to many of the internal checkout functions and removing the overload. This added some code, but it is probably a better implementation. There is some funkiness in the network code where user provided callbacks could be returning a positive or a negative value and we want to rely on that to cancel the loop. There are still a couple places where an user error might get turned into GIT_EUSER there, I think, though none exercised by the tests.
Russell Belfer committed -
This continues auditing all the places where GIT_EUSER is being returned and making sure to clear any existing error using the new giterr_user_cancel helper. As a result, places that relied on intercepting GIT_EUSER but having the old error preserved also needed to be cleaned up to correctly stash and then retrieve the actual error. Additionally, as I encountered places where error codes were not being propagated correctly, I tried to fix them up. A number of those fixes are included in the this commit as well.
Russell Belfer committed
-