Git 1.8 not working with Git plugin

[martinm.mail+trac@…]

Description

I've tried to set up Trac (deployed with lighttpd via FastCGI) with Git (managed by gitolite), but the source code browser always showed different error messages, depending on the settings:

If I've set these options

cached_repository = false
persistent_cache = false

I got an error saying No changeset None in the repository

If I set them to false, the error message said No changeset None in the repository.

Resyncing the repository with trac admin did not really work:

Resyncing repository history for testing... 
0 revisions cached.
Done.

Here are some lines from the error log:

2013-05-02 00:20:52,274 Trac[PyGIT] DEBUG: PyGIT.Storage instance 3358333124176 constructed
2013-05-02 00:20:52,274 Trac[PyGIT] DEBUG: requested weak PyGIT.Storage instance 3358333124176 for '/var/lib/gitolite/repositories/gitolite-admin.git'
2013-05-02 00:20:52,274 Trac[git_fs] DEBUG: disabled CachedRepository for '/var/lib/gitolite/repositories/gitolite-admin.git'
2013-05-02 00:20:52,276 Trac[PyGIT] DEBUG: triggered rebuild of commit tree db for 3358333124176
2013-05-02 00:20:52,316 Trac[PyGIT] DEBUG: rebuilt commit tree db for 3358333124176 with 0 entries (took 39.8 ms)
2013-05-02 00:20:52,333 Trac[main] WARNING: [87.122.134.50] HTTPNotFound: 404 No such node (No node conf/gitolite.conf at revision HEAD)

First I thought this was somehow related to ​Ticket #8844 on ​http://trac-hacks.org, because of the same symptoms, but after checking the permissions several times nothing changed really.

Luckily ​this Japanese Blog (tranlated with Google Translator) pointed out this is caused by using Git version 1.8.

After downgrading from Git 1.8.1.5 to 1.7.12.4 everything worked without changing anything.

How to reproduce

Using Git version 1.8.1.5 causes the error.

System information

OS: Gentoo Linux

Python: 3.2.3

[Jun Omae]

Cannot reproduced. Works for me with git 1.7.1 (CentOS 6), 1.7.4.1 (CentOS 5), 1.8.1.2 (Ubuntu 13.04) and 1.8.1.5 (Ubuntu 13.04).

Resyncing the repository with trac admin did not really work:

Resyncing repository history for testing... 
0 revisions cached.
Done.

No problem as cached_repository = false.

It seems that the issue depends on both the git repository data and the version of git, not only the version of git.

2013-05-02 00:20:52,333 Trac[main] WARNING: [87.122.134.50] HTTPNotFound: 404 No such node (No node conf/gitolite.conf at revision HEAD)

Could you please post the output (both stdout and stderr) of the following commands using both git 1.8.1.5 and 1.7.12.4?

sudo git --git-dir=/var/lib/gitolite/repositories/gitolite-admin.git ls-tree -l HEAD ''
sudo git --git-dir=/var/lib/gitolite/repositories/gitolite-admin.git ls-tree -l HEAD conf
sudo git --git-dir=/var/lib/gitolite/repositories/gitolite-admin.git ls-tree -l HEAD conf/
sudo git --git-dir=/var/lib/gitolite/repositories/gitolite-admin.git ls-tree -l HEAD conf/gitolite.conf

[martinm.mail+trac@…]

Trac configuration (with sanitized login credentials)

[martinm.mail+trac@…]

Gitolite configuration

[martinm.mail+trac@…]

Lighttpd configuration (for Trac deployment)

[martinm.mail+trac@…]

Thanks for your investigation on this issue, though it is strange this error is not simply reproducable. I'm trying to provide more information, so hopefully the reason can be found.

As requested, this is the output of the commands for Git version 1.7.12.4:

$ sudo git --git-dir=/var/lib/gitolite/repositories/gitolite-admin.git ls-tree -l HEAD ''
040000 tree ef33a246aab6136a91014ec46e6d1be99eb430ef       -    conf
$ sudo git --git-dir=/var/lib/gitolite/repositories/gitolite-admin.git ls-tree -l HEAD conf
040000 tree ef33a246aab6136a91014ec46e6d1be99eb430ef       -    conf
$ sudo git --git-dir=/var/lib/gitolite/repositories/gitolite-admin.git ls-tree -l HEAD conf/
100644 blob 6f03e06ed2ec7344811e5ef510856d3787e63c21      84    conf/gitolite.conf
$ sudo git --git-dir=/var/lib/gitolite/repositories/gitolite-admin.git ls-tree -l HEAD conf/gitolite.conf
100644 blob 6f03e06ed2ec7344811e5ef510856d3787e63c21      84    conf/gitolite.conf

And this is the output for Git version 1.8.1.5:

$ sudo git --git-dir=/var/lib/gitolite/repositories/gitolite-admin.git ls-tree -l HEAD ''
040000 tree ef33a246aab6136a91014ec46e6d1be99eb430ef       -    conf
040000 tree 5c892a08725657150c5aa33c7f523c1acb3fc0d4       -    keydir
$ sudo git --git-dir=/var/lib/gitolite/repositories/gitolite-admin.git ls-tree -l HEAD conf
040000 tree ef33a246aab6136a91014ec46e6d1be99eb430ef       -    conf
$ sudo git --git-dir=/var/lib/gitolite/repositories/gitolite-admin.git ls-tree -l HEAD conf/
100644 blob 6f03e06ed2ec7344811e5ef510856d3787e63c21      84    conf/gitolite.conf
$ sudo git --git-dir=/var/lib/gitolite/repositories/gitolite-admin.git ls-tree -l HEAD conf/gitolite.conf
100644 blob 6f03e06ed2ec7344811e5ef510856d3787e63c21      84    conf/gitolite.conf

Just for the records, these are some more software versions and configurations:

• Kernel: Linux 3.8.3-hardened
• Gitolite: 2.3.1
• Git compiled with: blksha1 cgi curl gpg iconv nls pcre perl python threads webdav

Additionally I've included the configuration files for Trac, Git and Lighttpd (with sanitized login credentials where neccessary)

[Jun Omae]

Thanks for letting us tell and the more information! But I cannot find any problems….

2013-05-02 00:20:52,316 Trac[PyGIT] DEBUG: rebuilt commit tree db for 3358333124176 with 0 entries (took 39.8 ms)

It seems that the git plugin cannot retrieve the revisions using git command (but, it is able to retrieve the directory listing).

I have another request. Could you please try the following with git 1.7.12.4 and 1.8.1.5? The git plugin retrieves all revisions using git rev-list --parents --topo-order --all.

git --git-dir=/var/lib/gitolite/repositories/gitolite-admin.git rev-list --max-count=1 --parents --topo-order --all

[martinm.mail+trac@…]

I ran the command git --git-dir=/var/lib/gitolite/repositories/gitolite-admin.git rev-list --max-count=1 --parents --topo-order --all with both versions:

This is the output for Git version 1.7.12.4 and version 1.8.1.5:

448221abd4d5319ccde56424c84e5d358df3ff60 7ba61601f55c366fd79f9979708a8396fde72316

Hope this helps!

[anonymous]

I find similar symptoms on my Gentoo Box with Python 2.7.3 and Git Trac 1.0.1

[anonymous]

Replying to anonymous:

I find similar symptoms on my Gentoo Box with Python 2.7.3 and Git Trac 1.0.1

Note that after restarting Apache all revisions are correctly displayed in the code browser.

[mrblur]

Well, I had the same issue on Gentoo x86, stable.

I tried keywording ~x86 on dev-vcs/git, and after upgrade to 1.8.3.2 my reposiotory is back :)

No apache reload needed.

[Jun Omae]

I have not reproduced it yet. But I guess the issue is related to permission problem.

Please verify no permission problems usgin git fsck with uid of your web server.

$ sudo -u web-server-uid git --git-dir /path/to/git-repo fsck

If no problems, please try 1.0-stable and TracLogging with DEBUG level. When git command returns non-zero or writes stderr, it will be logged.

[anonymous]

When I run the fsck command, I get an error: "fatal: Not a git repository: '/home/git/repositories/Project.git/'", but that is indeed the project I have cloned locally. And it works file. I am using gitolite, and followed the instructions at: ​https://help.ubuntu.com/13.10/serverguide/git.html

[Jun Omae]

When I run the fsck command, I get an error: "fatal: Not a git repository: '/home/git/repositories/Project.git/'", …

That is a git repository's permission problem and an InstallationIssue. I suppose that your web server cannot read the git repository. Make sure it is readable.

$ adduser www-data git

[anonymous]

I don't know what the issue would be with the permissions:

root@server:/var/log/apache2# adduser www-data git
The user `www-data' is already a member of `git'.

I can su to the www-data, cd to the Project.git directory, look at files, create files, etc.

Any idea what file/directory is the issue?

[anonymous]

strace to the rescue! I found the one folder that had no group X attrib. Thanks.

[Christian Boos]

Glad you figured it out! I admit the initial error was not really pointing there. Hopefully this ticket may help other people facing the same situation.