Open adamniedzielski opened 7 years ago
Some remarks:
Rugged::SORT_DATE
, if we don't specify this option it will return 0 commits. This suggests that it's a regression not a change of behavior, since sort order should not influence the number of returned items.Walker#hide
and then Walker#push
(as suggested in https://github.com/libgit2/rugged/issues/663#issue-199401672) it will return 0 commits. This also suggests that it's a regression, because the order of these two calls should not matter.0.25.0b9
and 0.25.0b10
- https://github.com/libgit2/rugged/commit/2e9db5c242b2c9d4b00f7a357471225ce0f01562. It includes significant changes to src/revwalk.c
.This sounds like a legit regression in libgit2. Could younplease open an issue on the actual repository (libgit2/libgit2) so they can fix it? We'll backport the fixed code. Thanks!
I believe this should be fixed in https://github.com/libgit2/rugged/pull/677 !
Can you please verify for your use case? Thanks!
@vmg No, unfortunately this is still not fixed in rugged
0.26.0b1.
RUGGED_VERSION=0.26.0b1 ruby rugged.rb
0.26.0b1
1
I rebased my failing test (https://github.com/libgit2/libgit2/pull/4100) against the current master
of libgit2
and it is still failing.
(but thanks for https://github.com/libgit2/libgit2/pull/4105 anyway 😄)
This is probably related to (https://github.com/libgit2/rugged/issues/663 /cc @cfillion).
Scenario:
Given a repository:
When we do:
Walker
returns 1 commit (commit A) instead of 0 commits. This happens only when usingRugged::SORT_DATE
.Script to reproduce