summaryrefslogtreecommitdiff
path: root/src/revwalk.c
Commit message (Collapse)AuthorAgeFilesLines
* revspec: rename git_revparse_mode_t to git_revspec_tethomson/revparseEdward Thomson2021-01-311-1/+1
| | | | | | The information about the type of a revision spec is not information about the parser. Name it accordingly, so that `git_revparse_mode_t` is now `git_revspec_t`. Deprecate the old name.
* revwalk: use GIT_ASSERTEdward Thomson2020-11-271-14/+31
|
* git_pool_init: handle failure casesethomson/poolinitEdward Thomson2020-06-011-5/+3
| | | | Propagate failures caused by pool initialization errors.
* push: check error code returned by `git_revwalk_hide`Patrick Steinhardt2020-02-071-1/+1
| | | | | | | | | | | | | | When queueing objects we want to push, we call `git_revwalk_hide` to hide all objects already known to the remote from our revwalk. We do not check its return value though, where the orginial intent was to ignore the case where the pushed OID is not a known committish. As `git_revwalk_hide` can fail due to other reasons like out-of-memory exceptions, we should still check its return value. Fix the issue by checking the function's return value, ignoring errors hinting that it's not a committish. As `git_revwalk__push_commit` currently clobbers these error codes, we need to adjust it as well in order to make it available downstream.
* revwalk functions: return an intEdward Thomson2020-01-241-3/+8
| | | | | Stop returning a void for functions, future-proofing them to allow them to fail.
* smart: implement by-date insertion when revwalkingEtienne Samson2019-08-231-1/+3
|
* revwalk: expose more ways of scheduling commitsEtienne Samson2019-08-231-18/+46
| | | | | | Before we can tweak the revwalk to be more efficent when negotiating, we need to add an "insertion mode" option. Since there's already an implicit set of those, make it visible, at least privately.
* revwalk: update error message for clarityEdward Thomson2019-05-121-1/+1
|
* revwalk: fix memory leak in error handlingHeiko Voigt2019-05-101-1/+2
| | | | | This is not implemented and should fail, but it should also not leak. To allow the memory debugger to find leaks and fix this one we test this.
* git_revwalk_push_range: do not crash if range is missingHeiko Voigt2019-05-031-0/+6
| | | | | If someone passes just one ref (i.e. "master") and misses passing the range we should be nice and return an error code instead of crashing.
* oidmap: introduce high-level setter for key/value pairsPatrick Steinhardt2019-02-151-5/+2
| | | | | | | | | | | | | | | Currently, one would use either `git_oidmap_insert` to insert key/value pairs into a map or `git_oidmap_put` to insert a key only. These function have historically been macros, which is why their syntax is kind of weird: instead of returning an error code directly, they instead have to be passed a pointer to where the return value shall be stored. This does not match libgit2's common idiom of directly returning error codes.Furthermore, `git_oidmap_put` is tightly coupled with implementation details of the map as it exposes the index of inserted entries. Introduce a new function `git_oidmap_set`, which takes as parameters the map, key and value and directly returns an error code. Convert all trivial callers of `git_oidmap_insert` and `git_oidmap_put` to make use of it.
* oidmap: introduce high-level getter for valuesPatrick Steinhardt2019-02-151-3/+2
| | | | | | | | | | | | | | The current way of looking up an entry from a map is tightly coupled with the map implementation, as one first has to look up the index of the key and then retrieve the associated value by using the index. As a caller, you usually do not care about any indices at all, though, so this is more complicated than really necessary. Furthermore, it invites for errors to happen if the correct error checking sequence is not being followed. Introduce a new high-level function `git_oidmap_get` that takes a map and a key and returns a pointer to the associated value if such a key exists. Otherwise, a `NULL` pointer is returned. Adjust all callers that can trivially be converted.
* maps: use uniform lifecycle management functionsPatrick Steinhardt2019-02-151-2/+2
| | | | | | | | | | | | | | | | Currently, the lifecycle functions for maps (allocation, deallocation, resize) are not named in a uniform way and do not have a uniform function signature. Rename the functions to fix that, and stick to libgit2's naming scheme of saying `git_foo_new`. This results in the following new interface for allocation: - `int git_<t>map_new(git_<t>map **out)` to allocate a new map, returning an error code if we ran out of memory - `void git_<t>map_free(git_<t>map *map)` to free a map - `void git_<t>map_clear(git<t>map *map)` to remove all entries from a map This commit also fixes all existing callers.
* git_error: use new names in internal APIs and usageEdward Thomson2019-01-221-10/+10
| | | | | Move to the `git_error` name in the internal API for error-related functions.
* object_type: use new enumeration namesethomson/index_fixesEdward Thomson2018-12-011-2/+2
| | | | Use the new object_type enumeration names within the codebase.
* Merge pull request #4888 from TheBB/add-cbPatrick Steinhardt2018-11-291-7/+3
|\ | | | | revwalk: Allow changing hide_cb
| * revwalk: Allow changing hide_cbEivind Fonn2018-11-281-7/+3
| | | | | | | | | | Since git_revwalk objects are encouraged to be reused, a public interface for changing hide_cb is desirable.
* | khash: remove intricate knowledge of khash typesPatrick Steinhardt2018-11-281-1/+1
|/ | | | | | | 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.
* revwalk: only check the first commit in the list for an earlier timestampcmn/revwalk-sign-regressionCarlos Martín Nieto2018-09-171-2/+8
| | | | | | | 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.
* revwalk: use the max value for a signed integerCarlos Martín Nieto2018-09-171-1/+1
| | | | | | | | | | | | | 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.
* revwalk: The left operand of '<' is a garbage valueEtienne Samson2018-08-211-1/+1
| | | | | | | | 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.
* revwalk: remove tautologic condition for hiding a commitJulian Ganz2018-07-291-2/+2
| | | | | The contition cannot be reached with `commit->uninteresting` being true: either a `break` or a `continue` statement will be hit in this case.
* Clear revwalk sorting when resettingNika Layzell2018-06-221-2/+3
| | | | | | | 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.
* Merge pull request #4606 from libgit2/cmn/revwalk-iterationEdward Thomson2018-06-181-9/+42
|\ | | | | revwalk: avoid walking the entire history when output is unsorted
| * revwalk: formatting updatescmn/revwalk-iterationEdward Thomson2018-06-181-17/+17
| |
| * revwalk: remove one useless layer of functionsCarlos Martín Nieto2018-04-111-32/+17
| | | | | | | | | | | | 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.
| * revwalk: avoid walking the entire history when output is unsortedCarlos Martín Nieto2018-04-011-9/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | Convert usage of `git_buf_free` to new `git_buf_dispose`Patrick Steinhardt2018-06-101-1/+1
| |
* | revwalk: fix uninteresting revs sometimes not limiting graphwalkPatrick Steinhardt2018-04-121-24/+9
|/ | | | | | | | | | | | | | | 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.
* Make sure to always include "common.h" firstPatrick Steinhardt2017-07-031-2/+2
| | | | | | | | | | | | | | | | | | | | | | 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.
* Skip uninteresting commits in revwalk timesort iteratorAdam Niedzielski2017-03-091-3/+6
| | | | Fixes #4099
* oidmap: remove GIT__USE_OIDMAP macroPatrick Steinhardt2017-02-171-2/+0
|
* khash: avoid using `kh_key`/`kh_val` as lvaluePatrick Steinhardt2017-02-171-1/+1
|
* khash: avoid using `kh_put` directlyPatrick Steinhardt2017-02-171-1/+1
|
* khash: avoid using `kh_val`/`kh_value` directlyPatrick Steinhardt2017-02-171-2/+2
|
* khash: avoid using `kh_get` directlyPatrick Steinhardt2017-02-171-1/+1
|
* khash: avoid using `kh_end` directlyPatrick Steinhardt2017-02-171-1/+1
|
* khash: avoid using `kh_foreach`/`kh_foreach_value` directlyPatrick Steinhardt2017-02-171-1/+1
|
* giterr_set: consistent error messagesEdward Thomson2016-12-291-3/+3
| | | | | | | | 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
* revwalk: do not re-declare `commit` variablePatrick Steinhardt2016-12-121-1/+1
|
* revwalk: don't show commits that become uninteresting after being enqueuedcmn/walk-limit-enoughCarlos Martín Nieto2016-10-061-8/+13
| | | | | | 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.
* revwalk: update the description for the default sortingCarlos Martín Nieto2016-10-061-4/+0
| | | | | | 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".
* revwalk: remove a useless enqueueing phase for topological and default sortingCarlos Martín Nieto2016-10-061-23/+22
| | | | | | | 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.
* revwalk: get rid of obsolete marking codeCarlos Martín Nieto2016-10-061-122/+9
| | | | | | | | | 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.
* revwalk: style changeCarlos Martín Nieto2016-10-061-4/+2
| | | | | Change the condition for returning 0 more in line with that we write elsewhere in the library.
* revwalk: port over the topological sortingCarlos Martín Nieto2016-10-061-47/+107
| | | | | | | | | 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`.
* revwalk: get closer to gitCarlos Martín Nieto2016-10-061-43/+174
| | | | | | | | | | | | 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.
* revwalk: use GITERR_CHECK_ALLOC_BUFPatrick Steinhardt2016-02-231-2/+1
|
* pool: Simplify implementationVicent Marti2015-10-281-4/+2
|
* Remove extra semicolon outside of a functionStefan Widgren2015-07-311-1/+1
| | | | | Without this change, compiling with gcc and pedantic generates warning: ISO C does not allow extra ‘;’ outside of a function.
View Lorry Controller Status