Grit::GitRuby::Repository.rev_list can produce results in the wrong order (parent before child) about grit HOT 7 CLOSED

Looks like GitHub-Flavoured Markdown was a bit too smart inside the code block there, those shouldn't be links of course...

from grit.

Crap, I clicked "comment and close" by accident! Can you please re-open? Thanks.

from grit.

Sounds reasonable to me. I feel like Grit::GitRuby should have some tests that compare the GitRuby implementation against the native git version too. If you could come up with a test case that passes with the native command, and fails with GitRuby, that'd be awesome.

from grit.

@technoweenie: I have created a repository with three commits; the second one was committed before the other ones (by setting the system clock). There's a clone at https://github.com/zmalltalker/strange_order/commits/master

I have a failing test that creates a Grit::Repo from this repo, collects the commits of it (repo.commits) and verifies that their SHAs are in the wrong order. This test is probably at a too high level, but I'm having a hard time figuring out how to target the tests in a better way, probably because I don't really get what Grit::GitRuby::Repository#rev_list actually does.

Would it help at all putting up that test case, or do you have any ideas on how to target the test better?

from grit.

@technoweenie I have a similar repo which exhibits this issue at https://github.com/philandstuff/grit-rev-list-problem-example

The following session demonstrates the difference in order between cmd-line git and git-ruby:

philippotter ~/tmp/grit-rev-list-problem-example $ git rev-list --pretty=raw master
commit 26c184858e44e109cc525632ed82d840b751bde6
tree 8a27fe8715be0cf38d8301c2eedadc180a787b02
parent e569728aceb65171508b07867610b1c36ad0f268
author Philip Potter <[email protected]> 1329836752 +0100
committer Philip Potter <[email protected]> 1329836752 +0100

    updated file nodes/dir/file.yaml

commit e569728aceb65171508b07867610b1c36ad0f268
tree 17b6d8b73adee6ea2139008db2c3eab2552ee860
author Philip Potter <[email protected]> 1329836752 +0100
committer Philip Potter <[email protected]> 1329836752 +0100

    first commit

philippotter ~/tmp/grit-rev-list-problem-example $ irb
>> require 'grit'
=> true
>> repo = Grit::Repo.new('.')
=> #<Grit::Repo "/Users/philippotter/tmp/grit-rev-list-problem-example/.git">
>> puts repo.git.rev_list({:pretty => "raw"})
commit e569728aceb65171508b07867610b1c36ad0f268
tree 17b6d8b73adee6ea2139008db2c3eab2552ee860
author Philip Potter <[email protected]> 1329836752 +0100
committer Philip Potter <[email protected]> 1329836752 +0100

    first commit

commit 26c184858e44e109cc525632ed82d840b751bde6
tree 8a27fe8715be0cf38d8301c2eedadc180a787b02
parent e569728aceb65171508b07867610b1c36ad0f268
author Philip Potter <[email protected]> 1329836752 +0100
committer Philip Potter <[email protected]> 1329836752 +0100

    updated file nodes/dir/file.yaml

=> nil

from grit.

Here's a simple fix for the case where the commit dates are equal(so like https://github.com/philandstuff/grit-rev-list-problem-example but not like https://github.com/zmalltalker/strange_order/commits/master ):

-        log = log.sort { |a, b| a[2] <=> b[2] }.reverse
+        log = log.sort_by.with_index { |a, i| [a[2], -i] }.reverse

This makes the sort stable (see http://bugs.ruby-lang.org/issues/1089) and is enough to fix the issue in this case. Since the commit dates of rebased commits are all equal, this is an important issue, see for example the wrong order at https://gitorious.org/~smarter/libav/smarter-libav/commits/hevc and the corresponding bug report at https://issues.gitorious.org/issues/94 .

from grit.

Grit is no longer maintained. See #183 and check out libgit2/rugged.

from grit.