Walker returns incorrect results after upgrade from 0.25.0b9 to 0.25.0b10
This is probably related to (https://github.com/libgit2/rugged/issues/663 /cc @cfillion).
Scenario:
Given a repository:
* commit C (HEAD)
|
* commit B
|
* commit A
When we do:
walker.push sha_of_a
walker.hide sha_of_c
Walker returns 1 commit (commit A) instead of 0 commits. This happens only when using Rugged::SORT_DATE.
Script to reproduce
gem 'rugged', "= #{ENV['RUGGED_VERSION']}"
require 'rugged'
require 'tmpdir'
Class.new do
def initialize
path = Dir.mktmpdir 'test-repository'
@repo = Rugged::Repository.init_at path
@repo.config['user.name'] = 'John Doe'
@repo.config['user.email'] = '[email protected]'
@hash_a = create_commit
sleep 1
@hash_b = create_commit
sleep 1
@hash_c = create_commit
puts Rugged::VERSION
compare
end
def create_commit
Rugged::Commit.create @repo,
message: 'Hello World',
parents: @repo.empty? ? [] : [@repo.head.target].compact,
tree: @repo.index.write_tree(@repo),
update_ref: 'HEAD'
end
def compare
walker = Rugged::Walker.new @repo
walker.sorting(Rugged::SORT_DATE)
walker.push @hash_a
walker.hide @hash_c
commits = walker.to_a
walker.reset
puts commits.size
end
end.new
> RUGGED_VERSION=0.25.0b9 ruby rugged.rb
0.25.0b9
0
> RUGGED_VERSION=0.25.0b10 ruby rugged.rb
0.25.0b10
1
Some remarks:
- It is specific to
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. - When we first call
Walker#hideand thenWalker#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. - There is one potential culprit between
0.25.0b9and0.25.0b10- https://github.com/libgit2/rugged/commit/2e9db5c242b2c9d4b00f7a357471225ce0f01562. It includes significant changes tosrc/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 😄)