Non-empty git repositories appear to be empty

Issue #25 invalid
Michael DePalatis created an issue

With git repositories, after I have pushed to the server, I frequently get an error message saying "There are no changesets yet" when clicking on Changelog using Firefox (both Windows and Linux).

It appears fairly consistent that if I press Changelog twice, I get the error message, then on the third time, it correctly shows the changelog. Pressing it once more repeats from the beginning showing the error message. The Summary view also frequently makes it look as if it were an empty repository. Clicking on the Files view results in 404 errors sometimes, unless I refresh.

Unfortunately, I don't seem to see anything useful in the log output. Pershaps this is a problem with how I've configured the logging. I am running Kallithea via uwsgi. Here is my relevant uwsgi section of the ini file:

master = true
socket = /tmp/kallithea.sock
pidfile = /tmp/
daemonize = /var/log/kallithea.log
http = :5001
processes = 4
virtualenv = /home/iontrap/kallithea

I have left the logger sections untouched from the default configuration. Maybe some change there would enable proper output to help diagnose the source of this problem?

Comments (15)

  1. Mads Kiilerich

    So Kallithea doesn't notice the repo changed after someone pushed. There is a "install git hook" option under admin. Have you used that?

  2. Mads Kiilerich

    Re instance_id: It can be set to '*' to assign it randomly. That do however mean that you should run paster cache-keys my.ini --cleanup regularly to avoid filling up the database.

    I have refactored this instance-id system so I kind of understand what it is doing. I'm quite sure it pretty much just can be removed and replaced with something simpler.

  3. Michael DePalatis reporter

    @domruf I switched to using 1 process and at least so far that appears to have solved the problem. There was no real reason for 4 processes, other than example uwsgi configuration files I was using did that (though for other applications).

    Any idea why this would have only affected git and not Mercurial repos?

  4. Michael DePalatis reporter

    The option under "Remap and rescan"? If I check that and rescan, all I see is

    Repositories successfully rescanned added: - ; removed: - 

    Again, no useful output in the server log. I'm also not completely clear on what this is supposed to be doing in the first place.

  5. Mads Kiilerich

    There should be hooks in place to update/expire Kallithea caches. Mercurial hooks pretty much just works. Git hooks are more tricky. Some digging around kallithea/lib/ might help figuring out what is going on.

    The hook should pretty much do the same as paster update-repoinfo my.ini --update-only=my/repo --invalidate-cache you can perhaps try running it manually.

    Does the same thing happen for git repos created from Kallithea and for 'scanned' repos?

  6. Michael DePalatis reporter

    digging around kallithea/lib/ might help figuring out what is going on.

    Thanks for the pointer. I'll look into it a bit more later this week.

    Does the same thing happen for git repos created from Kallithea and for 'scanned' repos?

    I only have Kallithea-created git repos at the moment.

  7. Michael DePalatis reporter

    Other than switching to use 1 process with uwsgi, no. Looking at the handle_git_receive function in kallithea/lib/ indicates that it executes a subprocess to do what it does, so that probably has something to do with it. This looks to be happening on lines 451, 457, and 465 with calls to repo.run_git_command. It would probably make more sense to use something like dulwich to read the repository rather than spawning subprocesses to run git commands.

  8. Mads Kiilerich

    Sure, pure dulwich would be better ... if it can do it. I assume there is a reason it is the way it is.

    But I doubt the callout to git is related to your issue.

    How is your instance_id configured?

  9. Mads Kiilerich

    The ini file template and says that it must be set uniquely if you run multiple instances - as you do. What you see is pretty much what you can expect with the configuration you have. Not a bug but incorrect configuration.

    The documentation could however be improved ... and we could reimplement this part of the system so it was less annoying. Contributions would be appreciated.

  10. Log in to comment