git log error when fetching changesets

[Lncn]

I was testing our installation last week by uploading a clone of the Linux Kernel. The fetch_changesets now generates this vague git error 141, which after some Googling, appears like it might be a pager error. (This is based on this thread I found..)

git log master error: git exited with non-zero status: 141
Executing RESYNC_ALL operation on gitolite configuration
Fetching changes from gitolite-admin repository to /tmp/redmine_git_hosting/git/gitolite-admin
Creating MD5 digests for Redmine Git Hosting hook
Digest for post-receive.redmine_gitolite.rb: 08e9b3cf99fa6285331ccdcef8b9a0d3
Our hook is already installed

I'm lost on how to debug this further. The repository tab of my Linux project opens but I don't see changesets. I'll post more as I explore...

[kubitron]

Wow. That's weird.

Two things to note: (1) the main update_repositories function seems to be working fine. (2) this is some sort of problem in either the redmine code or the interface between the redmine code and the plugin.

First of all, which version of Redmine and/or Chili?

Have you tried doing this without the plugin? (i.e. setting up a git SCM with a direct pointer to a repository).

[Lncn]

I'm running Redmine 1.3.0.

I haven't tried doing this without the plugin. Is there an easy way to do this without setting up another test installation? To be honest, setup was a pain for me as the network I use this on isn't connected to the internet.

One thing that's weird is that the "git exited with non-zero status" message is located in both the redmine code and this plugin. Is there an easier way to tell which module is actually printing this message? Again, excuse my Ruby incompetence. (I guess I could just add to the print messages in the respective location... printf debugging!)

[kubitron]

Actually, the plugin overrides the redmine code (that is why it appears to show up in both places). The way that the redmine repository code works (and by extension the plugin) is to use "git log" to get hashes for all of the commits on a particular branch. This complaint is about an attempt to read the commits from the master branch.

[kubitron]

Here is how to remove plugin -- just move the directory somewhere else and restart redmine. You can delete the repository (which will not remove it in the gitolite repo). Then, add another repo and point the url directly at the gitolite repository. You may need to temporarily change permissions on the gitolite repo so that it is directly readable by redmine. See whether you can do a fetch-changesets then....

[kubitron]

Anything new here?

[Lncn]

Yes, this wasn't the plugin as far as I could tell. I was able to workaround the problem by limiting the number of commit logs in the git_adapter.rb:

diff --git a/lib/redmine/scm/adapters/git_adapter.rb b/lib/redmine/scm/adapters/git_adapter.rb
index c0f190a..787ea2b 100755
--- a/lib/redmine/scm/adapters/git_adapter.rb
+++ b/lib/redmine/scm/adapters/git_adapter.rb
@@ -189,7 +189,7 @@ module Redmine

        def revisions(path, identifier_from, identifier_to, options={})
          revs = Revisions.new
-           cmd_args = %w|log --no-color --encoding=UTF-8 --raw --date=iso --pretty=fuller --parents|
+           cmd_args = %w|log --no-color -n 500 --encoding=UTF-8 --raw --date=iso --pretty=fuller --parents|
          cmd_args << "--reverse" if options[:reverse]
          cmd_args << "--all" if options[:all]
          cmd_args << "-n" << "#{options[:limit].to_i}" if options[:limit]

I actually checked the command line executed by the fetch_changesets from /proc and executed it myself as the git user:

git --git-dir repositories/mirror/linux.git -c core.quotepath=false -c log.decorate=no log --no-color --encoding=UTF-8 --raw --date=iso --pretty=fuller --parents --reverse master

And it took like 5 minutes to finish! I'm not convinced that the time should matter...

To be honest, I tried this before removing the plugin and as I was doing this on our production server, I'm reluctant to mess around much more with the setup and remove the plugin temporarily. One of these days I may get around to setting up a test Redmine installation in the office or here at my house and I can probably test it out without the plugin. You'll know better than I do, but it seems like the only thing that would cause this from the plugin is the GitCache, but I'm pretty sure that dude kicks in until we click the repository view from the browser.

I kind of don't really care to have the entire kernel commit history in our Redmine database anyways so I'm actually content with the way it is now.

[Lncn]

Oh I forgot to say, I removed the work around immediately after and everything still works as expected. I didn't realize this before, but it appears that redmine only does a git log "since" the last commit in the database?

[kubitron]

I'm thinking that perhaps there is a bug to submit to the redmine folks here... In your copious spare time, if you end up setting up a redmine-only site and try it again that would be good. If you get the same bug -- I think that a report on redmine.org is in order...

I'll assume you will tell me if this returns.

[Lncn]

I will! Another thing I forgot to mention is that I tried adding the --no-pager option as described in that thread I found, and that didn't change the error. Additionally I tried setting the GIT_PAGER environment variable in the crontab to cat which didn't change anything either.

I hope the "copious spare time" wasn't being too sarcastic... Haha. This just isn't my typical job at work, and consequently I'm not that familiar with system administration or Ruby. I was volunteered to replace our old issue tracker at work because I was the most vocal with complaints about it and how cumbersome SVN was getting for our workflow. So far Redmine and this plugin have been awesome, except for a few minor hiccups which I've been able to work around. Excellent job upgrading this by the way! I'll get to submitting this to redmine.org before too long. I did search around and saw this interesting issue from a while back specifically referring to a linux kernel import. I may try and git svn clone our largest SVN repo tomorrow and see if it can handle a little over 10,000 commits in a single fetch_changesets. It's probably not quite comparable to the 300,000 changesets in the kernel, but it's a considerable step up from the 500 changesets that I limited it to.

I'll let you know.

[kubitron]

Heaven forbid! I wasn't trying to be sarcastic. Just joking that I was asking you to do more work. Everyone is volunteering there time here.

Thanks for putting up with the bugs you've encountered. I ended up maintaining this plugin because I needed something stable (and you have helped get it to be more stable.) Thanks.

[tomascohen]

is -n 500 overriding what is set in this line?

cmd_args << "-n" << "#{options[:limit].to_i}" if options[:limit]

It doesn't make any sense that this solves the problem. Maybe the problem has to do with memory available for the process? So it cannot handle the whole piped data?