| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
| |
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`.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Introduce some tests that show some commits, while hiding some commits
that have a timestamp older than the common ancestors of these two
commits.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
We moved the "main" parsing to use 64 bits for the timestamp, but the
quick parsing for the revwalk did not. This means that for large
timestamps we fail to parse the time and thus the walk.
Move this parser to use 64 bits as well.
|
| |
|
|
|
| |
When we hide a commit which we later push into the revwalk, we do not
handle this well and return commits which we should not.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\
| |
| | |
merge: expose multiple merge bases
|
| | |
| |
| |
| |
| |
| |
| |
| | |
We always calculate multiple merge bases, but up to now we had only
exposed the "best" merge base.
Introduce git_oidarray which analogously to git_strarray lets us return
multiple ids.
|
| |/
|
|
|
| |
The logic was reversed. I have checked manually each pair with git and
adjusted the expectation to what git status prints.
|
| |
|
|
|
|
| |
The revwalk::simplify test was not actually tested the values from
the revwalk against the expected. (Further, the expected had two
IDs transposed.)
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
If the pqueue comparison fn returned just 0 or 1 (think "a<b")
then the sort order of returned items could be wrong because there
was a "< 0" that really needed to be "<= 0". Yikes!!!
|
| |
|
|
| |
This used to be broken, let's make sure we don't break this use-case.
|
| |
|
|
|
| |
Pushing a whole namespace can cause us to attempt to push non-committish
objects. Catch this situation and special-case it for ignoring this.
|
| |
|
|
| |
This shows that pusing a whole namespace can be problematic.
|
| |
|