Error 500 when browsing project files
Created by: rtripault
On some projects, the following error is raised when browsing files : ActionView::Template::Error (undefined methodcommitted_date' for nil:NilClass):`
The "pattern" seems to occur on "old" projects. Did i miss some task to perform ? Thanks
Gitlab 5.1, 248b2554
System information
System: Debian 6.0.7
Current User: git
Using RVM: no
Ruby Version: 1.9.3p392
Gem Version: 2.0.3
Bundler Version:1.3.5
Rake Version: 10.0.4Activity
Created by: swiegreffe
Same here. Also noteworthy: On the dashboard the "latest Activity" says "never". Server-Setup in my case differs from the recommended setup at least in so far that I'm running Gitlab with Phusion Passenger.
By Administrator on 2013-04-22T15:42:24 (imported from GitLab project)
By Administrator on 2013-04-22T15:42:24 (imported from GitLab)
Created by: Deradon
This commit breaks it for me: https://github.com/gitlabhq/gitlabhq/commit/b1a8fdd84d5a7cdbdb5ef3829b59a73db0f4d2dd
Everythin is working, when I revert this.
By Administrator on 2013-04-22T21:39:16 (imported from GitLab project)
By Administrator on 2013-04-22T21:39:16 (imported from GitLab)
Created by: drewblessing
The issue mentioned by @Deradon is also affecting me. With the change everything was broken and when rolling back that 2 lines of code, life is good. We need to find a long term fix for this ASAP.
By Administrator on 2013-04-23T03:06:54 (imported from GitLab project)
By Administrator on 2013-04-23T03:06:54 (imported from GitLab)
Created by: rtripault
@Akzhan not really, this PR fixes problem when switching branch while viewing a file. Anyway, thanks @Deradon , setting
follow: falsedid the trick (as a temporary work around). Closing the issue here in favor of #3666 (closed)By Administrator on 2013-04-23T08:55:29 (imported from GitLab project)
By Administrator on 2013-04-23T08:55:29 (imported from GitLab)
Created by: Deradon
As @rtripault allready said, by PR above don't fix this issue here.
By Administrator on 2013-04-23T09:16:44 (imported from GitLab project)
By Administrator on 2013-04-23T09:16:44 (imported from GitLab)
Created by: akzhan
Please take a look at https://github.com/akzhan/gitlabhq/commit/33a10748380f9d8879855d3b1237120d8ac3ce9d
It should fix this issue.
By Administrator on 2013-04-23T12:21:22 (imported from GitLab project)
By Administrator on 2013-04-23T12:21:22 (imported from GitLab)
Created by: zzjin
@Akzhan can u give any futher info mation about "upgrade git itself"? add: #3666 (closed) works fine
By Administrator on 2013-04-25T01:52:13 (imported from GitLab project)
By Administrator on 2013-04-25T01:52:13 (imported from GitLab)
Created by: untergeek
Upgrading to git 1.8.7 did not fix for me, even when combined with 33a10748. Reverting b1a8fdd8 as @Deradon suggests did fix. Also, there will be a LOT of people using RHEL or CentOS (even 6.4) which are using 1.7.1. If the eventual resolution is going to force upgrades it could get ugly.
By Administrator on 2013-04-25T17:12:42 (imported from GitLab project)
By Administrator on 2013-04-25T17:12:42 (imported from GitLab)
Created by: akzhan
@zzjin As mentioned in another #3666 (closed) thread, upgrade of
gitto 1.7.10 or higher resolves the issue for nearby all users.By Administrator on 2013-04-25T17:44:48 (imported from GitLab project)
By Administrator on 2013-04-25T17:44:48 (imported from GitLab)
Created by: untergeek
The only difference between my problem instance and another stock instance is that my relative path adds /git on the end. Not sure if that makes a difference, but it might.
By Administrator on 2013-04-25T21:21:31 (imported from GitLab project)
By Administrator on 2013-04-25T21:21:31 (imported from GitLab)
Created by: drewblessing
I agree with @untergeek. Centos/Redhat users everywhere are going to scream. Is whatever feature in the newer versions of git really necessary? Can we use something else that doesn't rely on > 1.7.1?
By Administrator on 2013-04-26T13:37:59 (imported from GitLab project)
By Administrator on 2013-04-26T13:37:59 (imported from GitLab)
Created by: untergeek
$ git --version git version 1.8.2.1.628.gcd33b41
Don't know quite where that 7 came from :) Anyway, I don't think the path is in question. It works just fine with the reversion. My updated git version is in the same path as the previous one, too.
By Administrator on 2013-04-26T22:06:15 (imported from GitLab project)
By Administrator on 2013-04-26T22:06:15 (imported from GitLab)
Created by: drewblessing
@hiroponz There's no denying that 1.7.1 is older. The issue is that is the latest found in any redhat/centos repo. Requiring something newer is a big inconvenience for all those distro users. Even Ruby 1.9.3 is a huge inconvenience but at least rvm makes that more palatable for us. If its possible to use a way that isn't reliant on git 1.7.10+ I think it should be explored.
By Administrator on 2013-04-26T22:27:27 (imported from GitLab project)
By Administrator on 2013-04-26T22:27:27 (imported from GitLab)
Created by: hiroponz
@drewblessing I am using with centos6. I have installed git from yum package and source. I can't remove yum package because of some dependencies. There are
/usr/bin/git(1.7.1) and/usr/local/bin/git(1.8.2), and there is no problem in my case, if #3687 is applied and editgit: bin_path:in gitlab.yml to point/usr/local/bin/git.Sorry, I may misunderstand.
By Administrator on 2013-04-26T23:13:31 (imported from GitLab project)
By Administrator on 2013-04-26T23:13:31 (imported from GitLab)
Created by: holderbaum
There is no point in changing bin_path in your config. You should make sure, that your PATH is all correct, that is my default setting on CentOS:
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/root/binSince gitlab is startet via a sudo, you must also ensure, thath the correct PATH is set by this nifty little tool. Type
visudo, search forDefaults secure_path = ...and configure it accordingly.Now, your systems uses installations from /usr/local with precedence over /usr, just how it's meant to be on a unix flavoured system.
Those modifications plus your tip of installing git 1.8 from source (remember, use
make prefix=/usr/local ...) fixed the issue for me.Greetings!
By Administrator on 2013-05-04T05:20:13 (imported from GitLab project)
By Administrator on 2013-05-04T05:20:13 (imported from GitLab)
Created by: JB1tz
The way I resolved the issue was to install 1.8.2.2 with a local user prefix and adjust my $PATH accordingly. This also allows for specifying/testing various versions of git with gitlab without too much fuss.
sudo yum install -y perl-ExtUtils-MakeMaker gettext-devel expat-devel curl-devel \ zlib-devel openssl-devel openssl-devel gcc-c++ make sudo su - git mkdir -p /home/git/git git clone -b maint https://github.com/git/git.git git-src cd git-src make prefix=/home/git/git installAnd modified $PATH in '/home/git/.bash_profile' to match what's below.
PATH=$HOME/git/bin:$PATH:$HOME/binBy Administrator on 2013-05-07T03:48:41 (imported from GitLab project)
By Administrator on 2013-05-07T03:48:41 (imported from GitLab)
