- 22 Jan, 2019 1 commit
-
-
Move to the `git_error` name in the internal API for error-related functions.
Edward Thomson committed
-
- 01 Dec, 2018 1 commit
-
-
Use the new object_type enumeration names within the codebase.
Edward Thomson committed
-
- 28 Nov, 2018 2 commits
-
-
Instead of using the `khiter_t`, `git_strmap_iter` and `khint_t` types, simply use `size_t` instead. This decouples code from the khash stuff and makes it possible to move the khash includes into the implementation files.
Patrick Steinhardt committed -
Since git_revwalk objects are encouraged to be reused, a public interface for changing hide_cb is desirable.
Eivind Fonn committed
-
- 17 Sep, 2018 2 commits
-
-
This is not a big deal, but it does make us match git more closely by checking only the first. The lists are sorted already, so there should be no functional difference other than removing a possible check from every iteration in the loop.
Carlos Martín Nieto committed -
When porting, we overlooked that the difference between git's and our's time representation and copied their way of getting the max value. Unfortunately git was using unsigned integers, so `~0ll` does correspond to their max value, whereas for us it corresponds to `-1`. This means that we always consider the last date to be smaller than the current commit's and always think commits are interesting. Change the initial value to the macro that gives us the maximum value on each platform so we can accurately consider commits interesting or not.
Carlos Martín Nieto committed
-
- 20 Aug, 2018 1 commit
-
-
At line 594, we do this : if (error < 0) return error; but if nothing was pushed in a GIT_SORT_TIME revwalk, we'd return uninitialized stack data.
Etienne Samson committed
-
- 29 Jul, 2018 1 commit
-
-
The contition cannot be reached with `commit->uninteresting` being true: either a `break` or a `continue` statement will be hit in this case.
Julian Ganz committed
-
- 22 Jun, 2018 1 commit
-
-
Currently we fail to clear the sorting flag for revwalks when resetting. This caused a poor interaction with the limited flag during a recent patch. This patch clears the revwalk sorting flag and causes it to no longer persist over resets.
Nika Layzell committed
-
- 18 Jun, 2018 1 commit
-
-
Edward Thomson committed
-
- 10 Jun, 2018 1 commit
-
-
Patrick Steinhardt committed
-
- 12 Apr, 2018 2 commits
-
-
When we want to limit our graphwalk, we use the heuristic of checking whether the newest limiting (uninteresting) revision is newer than the oldest interesting revision. We do so by inspecting whether the first item's commit time of the user-supplied list of revisions is newer than the last added interesting revision. This is wrong though, as the user supplied list is in no way guaranteed to be sorted by increasing commit dates. This could lead us to abort the revwalk early before applying all relevant limiting revisions, outputting revisions which should in fact have been hidden. Fix the heuristic by instead checking whether _any_ of the limiting commits was made earlier than the last interesting commit. Add a test.
Patrick Steinhardt committed -
We don't currently need to have anything that's different between `get_revision` and `get_one_revision` so let's just remove the inner function and make the code more straightforward.
Carlos Martín Nieto committed
-
- 01 Apr, 2018 1 commit
-
-
As part of reducing our divergence from git, its code for revwalk was ported into our codebase. A detail about when to limit the list was lost and we ended up always calling that code. Limiting the list means performing the walk and creating the final list of commits to be output during the preparation stage. This is unavoidable when sorting and when there are negative refs. We did this even when asked for unsorted output with no negative refs, which you might do to retrieve something like the "last 10 commits on HEAD" for a nominally unsorted meaning of "last". This commit adds and sets a flag indicating when we do need to limit the list, letting us avoid doing so when we can. The previously mentioned query thus no longer loads the entire history of the project during the prepare stage, but loads it iteratively during the walk.
Carlos Martín Nieto committed
-
- 03 Jul, 2017 1 commit
-
-
Next to including several files, our "common.h" header also declares various macros which are then used throughout the project. As such, we have to make sure to always include this file first in all implementation files. Otherwise, we might encounter problems or even silent behavioural differences due to macros or defines not being defined as they should be. So in fact, our header and implementation files should make sure to always include "common.h" first. This commit does so by establishing a common include pattern. Header files inside of "src" will now always include "common.h" as its first other file, separated by a newline from all the other includes to make it stand out as special. There are two cases for the implementation files. If they do have a matching header file, they will always include this one first, leading to "common.h" being transitively included as first file. If they do not have a matching header file, they instead include "common.h" as first file themselves. This fixes the outlined problems and will become our standard practice for header and source files inside of the "src/" from now on.
Patrick Steinhardt committed
-
- 09 Mar, 2017 1 commit
-
-
Fixes #4099
Adam Niedzielski committed
-
- 17 Feb, 2017 7 commits
-
-
Patrick Steinhardt committed
-
Patrick Steinhardt committed
-
Patrick Steinhardt committed
-
Patrick Steinhardt committed
-
Patrick Steinhardt committed
-
Patrick Steinhardt committed
-
Patrick Steinhardt committed
-
- 29 Dec, 2016 1 commit
-
-
Error messages should be sentence fragments, and therefore: 1. Should not begin with a capital letter, 2. Should not conclude with punctuation, and 3. Should not end a sentence and begin a new one
Edward Thomson committed
-
- 12 Dec, 2016 1 commit
-
-
Patrick Steinhardt committed
-
- 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
-