- 06 Oct, 2016 7 commits
-
-
When we read from the list which `limit_list()` gives us, we need to check that the commit is still interesting, as it might have become uninteresting after it was added to the list.
Carlos Martín Nieto committed -
It changed from implementation-defined to git's default sorting, as there are systems (e.g. rebase) which depend on this order. Also specify more explicitly how you can get git's "date-order".
Carlos Martín Nieto committed -
After `limit_list()` we already have the list in time-sorted order, which is what we want in the "default" case. Enqueueing into the "unsorted" list would just reverse it, and the topological sort will do its own sorting if it needs to.
Carlos Martín Nieto committed -
We've now moved to code that's closer to git and produces the output during the preparation phase, so we no longer process the commits as part of generating the output. This makes a chunk of code redundant, as we're simply short-circuiting it by detecting we've processed the commits alrady.
Carlos Martín Nieto committed -
Change the condition for returning 0 more in line with that we write elsewhere in the library.
Carlos Martín Nieto committed -
After porting over the commit hiding and selection we were still left with mistmaching output due to the topologial sort. This ports the topological sorting code to make us match with our equivalent of `--date-order` and `--topo-order` against the output from `rev-list`.
Carlos Martín Nieto committed -
We had some home-grown logic to figure out which objects to show during the revision walk, but it was rather inefficient, looking over the same list multiple times to figure out when we had run out of interesting commits. We now use the lists in a smarter way. We also introduce the slop mechanism to determine when to stpo looking. When we run out of interesting objects, we continue preparing the walk for another 5 rounds in order to make it less likely that we miss objects in situations with complex graphs.
Carlos Martín Nieto committed
-
- 23 Feb, 2016 1 commit
-
-
Patrick Steinhardt committed
-
- 28 Oct, 2015 1 commit
-
-
Vicent Marti committed
-
- 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
-
- 14 Apr, 2015 1 commit
-
-
When walking backwards and marking parents uninteresting, make sure we detect when the list of commits we have left has run out of uninteresting commits so we can stop marking commits as uninteresting. Failing to do so can mean that we walk the whole history marking everything uninteresting, which eats up time, CPU and IO for with useless work. While pre-marking does look for this, we still need to check during the main traversal as there are setups for which pre-marking does not leave enough information in the commits. This can happen if we push a commit and hide its parent.
Carlos Martín Nieto committed
-
- 08 Apr, 2015 1 commit
-
-
When a commit is first set as unintersting and then pushed, we must take care that we do not put it into the commit list as that makes us return at least that commit (but maybe more) as we've inserted it into the list because we have the assumption that we want anything in the commit list.
Carlos Martín Nieto 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
-
- 13 Feb, 2015 1 commit
-
-
Introduce some helper macros to test integer overflow from arithmetic and set error message appropriately.
Edward Thomson committed
-
- 22 Nov, 2014 1 commit
-
-
There are some combination of objects and target types which we know cannot be fulfilled. Return EINVALIDSPEC for those to signify that there is a mismatch in the user-provided data and what the object model is capable of satisfying. If we start at a tag and in the course of peeling find out that we cannot reach a particular type, we return EPEEL.
Carlos Martín Nieto committed
-
- 08 Oct, 2014 5 commits
-
-
This should have been included when implementing the feature but was missed.
Carlos Martín Nieto committed -
If there have been no pushes, we can immediately return ITEROVER. If there have been no hides, we must not run the uninteresting pre-mark phase, as we do not want to hide anything and this would simply cause us to spend time loading objects.
Carlos Martín Nieto committed -
This introduces a phase at the start of preparing a walk which pre-marks uninteresting commits, but only up to the common ancestors. We do this in a similar way to git, by walking down the history and marking (which is what we used to do), but we keep a time-sorted priority queue of commits and stop marking as soon as there are only uninteresting commits in this queue. This is a similar rule to the one used to find the merge-base. As we keep inserting commits regardless of the uninteresting bit, if there are only uninteresting commits in the queue, it means we've run out of interesting commits in our walk, so we can stop. The old mark_unintesting() logic is still in place, but that stops walking if it finds an already-uninteresting commit, so it will stop on the ones we've pre-marked; but keeping it allows us to also hide those that are hidden via the callback.
Carlos Martín Nieto committed -
The old separation was due to the old merge-base finding, so it's no longer necessary.
Carlos Martín Nieto committed -
These store merge-base information which is only valid for a single run.
Carlos Martín Nieto committed
-
- 24 Jul, 2014 1 commit
-
-
Preallocating two commits doesn't make much sense as leaving allocation to the first array usage will allocate a sensible size with room for growth. This preallocation has also been hiding issues with strict aliasing in the tests, as we have fairly simple histories and never trigger the growth.
Carlos Martín Nieto committed
-
- 10 Jun, 2014 1 commit
-
-
Instead of using a sentinel empty value to detect the last commit, let's check for when we get a NULL from popping the stack, which lets us know when we're done. The current code causes us to read uninitialized data, although only on RHEL/CentOS 6 in release mode. This is a readability win overall.
Carlos Martín Nieto committed
-
- 31 Mar, 2014 1 commit
-
-
Anurag Gupta committed
-
- 24 Mar, 2014 3 commits
-
-
Anurag Gupta committed
-
Anurag Gupta committed
-
Anurag Gupta committed
-
- 20 Mar, 2014 1 commit
-
-
As a way to speed up the cases where we need to hide some commits, we find out what the merge bases are so we know to stop marking commits as uninteresting and avoid walking down a potentially very large amount of commits which we will never see. There are however two oversights in current code. The merge-base finding algorithm fails to recognize that if it is only given one commit, there can be no merge base. It instead walks down the whole ancestor chain needlessly. Make it return an empty list immediately in this situation. The revwalk does not know whether the user has asked to hide any commits at all. In situation where the user pushes multiple commits but doesn't hide any, the above fix wouldn't do the trick. Keep track of whether the user wants to hide any commits and only run the merge-base finding algorithm when it's needed.
Carlos Martín Nieto committed
-
- 05 Feb, 2014 3 commits
-
-
Carlos Martín Nieto committed
-
Pushing a whole namespace can cause us to attempt to push non-committish objects. Catch this situation and special-case it for ignoring this.
Carlos Martín Nieto committed -
Let the user push committish objects and peel them to figure out which commit to push to our queue. This is for convenience and for allowing uses of git_revwalk_push_glob(w, "tags") with annotated tags.
Carlos Martín Nieto committed
-
- 04 Feb, 2014 2 commits
-
-
This updates the git_pqueue to simply be a set of specialized init/insert/pop functions on a git_vector. To preserve the pqueue feature of having a fixed size heap, I converted the "sorted" field in git_vectors to a more general "flags" field so that pqueue could mix in it's own flag. This had a bunch of ramifications because a number of places were directly looking at the vector "sorted" field - I added a couple new git_vector helpers (is_sorted, set_sorted) so the specific representation of this information could be abstracted.
Russell Belfer committed -
I accidentally wrote a separate priority queue implementation when I was working on file rename detection as part of the file hash signature calculation code. To simplify licensing terms, I just adapted that to a general purpose priority queue and replace the old priority queue implementation that was borrowed from elsewhere. This also removes parts of the COPYING document that no longer apply to libgit2.
Russell Belfer committed
-
- 11 Dec, 2013 2 commits
-
-
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
-
- 23 Sep, 2013 1 commit
-
-
In revwalk, we are doing a very simple check to see if a string contains wildcard characters, so a full regular expression match is not needed. In remote listing, now that we have git_config_foreach_match with full regular expression matching, we can take advantage of that and eliminate the regex here, replacing it with much simpler string manipulation.
Russell Belfer committed
-
- 09 Sep, 2013 1 commit
-
-
When enabled, only the first parent of each commit will be queued, enabling a simple way of using first-parent simplification.
Carlos Martín Nieto committed
-
- 06 Sep, 2013 1 commit
-
-
Using a recursive function can blow the stack when dealing with long histories. Use a loop instead to limit the call chain depth. This fixes #1223.
Carlos Martín Nieto committed
-
- 11 May, 2013 1 commit
-
-
Nobody should ever be using anything other than ALL at this level, so remove the option altogether. As part of this, git_reference_foreach_glob is now implemented in the frontend using an iterator. Backends will later regain the ability of doing the glob filtering in the backend.
Carlos Martín Nieto committed
-
- 15 Apr, 2013 2 commits
-
-
Vicent Marti committed
-
Vicent Marti committed
-