Antsu, Thank you for your investigation of the comparison bug. A Gitlab issue for this bug was first opened here https://github.com/gitlabhq/gitlabhq/issues/8174 21 days ago by GitHub user lokeshkumar. I commented on that issue stating that I encountered the same problem and that my investigation led me to the same conclusion that you arrived at: a problem with the walker routine in the Rugged gem related to a problem with libgit2. I filed a separate issue for the Rugged gem here: https://github.com/libgit2/rugged/issues/431. The issue has since been fixed by the Rugged developers. Once they release a non-beta patch to the Rugged gem, Gitlab will likely bump the version number of the Rugged dependency which will fix the issue upstream.
Cheers, -Alex On Fri, Nov 14, 2014 at 3:29 AM, Antsu Haapa <[email protected]> wrote: > Here is a description of the problem we have been having, and I hope this > helps also someone else having the same problem: > > We are using GitLab 7.4.3 353a987 on CentOS release 6.4 (Final). > > When creating merge requests, most of the time, the MR shows all > historical commits (tens of thousands of commits) from the repository > instead of the ones in the feature branch. > The problem occurs when the master branch has new commits since the > feature branch was started. > > We investigated the cause of the problem: > > GitLab code calls: > > Gitlab::Git::Compare.new( > target_project.repository.raw_repository, > target_branch, > source_branch, > ) > > And that calls: > > compare.rb: @commits = Gitlab::Git::Commit.between(repository, @base.id, @ > head.id) > > And that calls: > commit.rb: repo.commits_between(base, head) > > And that has been implemented like: > def commits_between(from, to) > walker = Rugged::Walker.new(rugged) > walker.push(to) > walker.hide(from) > commits = walker.to_a > walker.reset > The problem is that walker.hide('master') does NOT hide all historical > commits as it should. > And the root cause is in libgit2's (rugged-0.21.0) function > mark_uninteresting() in revwalk.c, > and more precisely in: > > git_commit_list_node **node = git_array_alloc(pending); > > That macro is defined in array.h: > > #define git_array_alloc(a) \ > (((a).size >= (a).asize) ? \ > git_array_grow(&(a), sizeof(*(a).ptr)) : \ > ((a).ptr ? &(a).ptr[(a).size++] : NULL)) > > The problem is that git_array_grow() has code fragment: > a->ptr = new_array; a->asize = new_size; a->size++; > return a->ptr + (a->size - 1) * item_size; > > which is incorrectly optimized by GCC (4.4.7 20120313 (Red Hat 4.4.7-11)) > so that the return value is not > the address of the last item in array, but the second last, and that > results in early termination of mark_uninteresting() > because there is a NULL value in the pending array. > > We recompiled the Rugged gem and its libgit2 without "-O2" compiler flag, > and everything started to work correctly. > Many other GCC versions do not have the problem (3.4, 4.1). Attached is C > code to reproduce the compiler problem. > > Antsu Haapa > > -- > You received this message because you are subscribed to the Google Groups > "GitLab" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/gitlabhq/d4ef27e8-d867-465d-a005-59311ff657e3%40googlegroups.com > <https://groups.google.com/d/msgid/gitlabhq/d4ef27e8-d867-465d-a005-59311ff657e3%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "GitLab" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/gitlabhq/CAGWx_yahP-Sw%3DoybdFsEJiEMw-Ei7%2B9h%3Dyx4jfkH8eUNu6VKzw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
