No repositories causes RuntimeException

[uuf6429]

I don't know if this has been fixed, since I only tested it on the stable release (0.3).

Basically, if there are no repositores, a RuntimeException is thrown with message "There are no GIT repositories in /var/www/html/".

While I think the error is self explanatory (and its occurrence does not cause me issues), I think it is best if a page with "No Repositories Found" would be quite better.

[ArvinB]

I have the same issue, but I have a --bare repository where it has been updated from other local ones through a push. Is this expected or what am I doing wrong here?

--- Update: 11 Hours later, I got this working. Was it worth it, HELL YES! GITList looks AWESOME!

Here is what I did to fix it for me, so I hope it helps someone else.

Quick Summary: Changed permissions on my repository folder. Credit goes to StackOverflow

I am using OS X Mountain Lion with Apache. I had to go into Apache as root to enable it and configure it. All that went pretty much as expected. Defaults to ~/MyUser/Sites/... so I put gitlist in here. My repositories though were elsewhere, namely ~/MyUser/Repo/... all are --bare repositories for me to push code into. Basically on OS Mountain Lion Apache runs under the _www group and so permissions were necessary (see link). What took me so long to figure this out was because the page kept indicating that no repositories were found, so I assumed it was reading everything ok. If somehow another check before the if statement on permissions can be made, then that might be a wise move.

[klaussilveira]

We will check for read permissions on the next version.

[uuf6429]

Uhm, this problem isn't about just read permissions. If the folder is empty, we get this error message. Ideally a better message should show up depending on what actually is happening (empty vs permissions, for instance).

[ArvinB]

I agree budŠI am a novice when it comes to php.

I am more of an Objective-C developer / software systems architect specializing in Mac OS X and iOS.

What I sent you checks for a dir && read permissions because Symbolic Links will always return true for read permissions.

Let me know if I can contribute more.

Thanks, Arvin

From: Christian Sciberras notifications@github.com Reply-To: klaussilveira/gitlist <reply+i-7798333-0f9010aacca1723a3220c1f70a3b2ce0830d4517-1202744@reply.gith ub.com> Date: Tuesday, February 19, 2013 9:33 AM To: klaussilveira/gitlist gitlist@noreply.github.com Cc: Arvin Bhatnagar arvinb@columbus.rr.com Subject: Re: [gitlist] No repositories causes RuntimeException (#195)

Uhm, this problem isn't about just read permissions. If the folder is empty, we get this error message. Ideally a better message should show up depending on what actually is happening (empty vs permissions, for instance).

‹ Reply to this email directly or view it on GitHub https://github.com/klaussilveira/gitlist/issues/195#issuecomment-13775070 .

[khyox]

I am suffering this issue only with the development build and it is not a problem related with permissions nor the folder is empty (GitWeb and the latest stable of GitList with the same config are both reading the repositories). This is the error I get in the lighttpd error log:

(mod_fastcgi.c.2676) FastCGI-stderr: PHP Fatal error: Uncaught exception 'RuntimeException' with message 'There are no GIT repositories in /home/git/' in /var/www/lighttpd/gitlist_build/vendor/klaussilveira/gitter/lib/Gitter/Client.php:244

[wimrijnders]

HI @khyox,

Do the repo's in the directory have an extension '.git' in the name?

If so, the issue is fixed in #304. Would you mind to update the development build, click on 'Refresh' and see if this fixes it?

[khyox]

Hi! Yes, there is only one repository with '.git' in the name.

The problem is still there. Here you are the stack trace:

(mod_fastcgi.c.2676) FastCGI-stderr: PHP Fatal error: Uncaught exception 'RuntimeException' with message 'There are no GIT repositories in /home/git/' in /var/www/lighttpd/gitlist_lastbuild/vendor/klaussilveira/gitter/lib/Gitter/Client.php:244 Stack trace:

0 /var/www/lighttpd/gitlist_lastbuild/src/GitList/Util/Routing.php(121): Gitter\Client->getRepositories(Array)

1 /var/www/lighttpd/gitlist_lastbuild/src/GitList/Controller/MainController.php(51): GitList\Util\Routing->getRepositoryRegex()

2 /var/www/lighttpd/gitlist_lastbuild/vendor/silex/silex/src/Silex/Application.php(458): GitList\Controller\MainController->connect(Object(GitList\Application))

3 /var/www/lighttpd/gitlist_lastbuild/boot.php(28): Silex\Application->mount('', Object(GitList\Controller\MainController))

4 /var/www/lighttpd/gitlist_lastbuild/index.php(22): require('/var/www/lightt...')

5 {main}

thrown in /var/www/lighttpd/gitlist_lastbuild/vendor/klaussilveira/gitter/lib/Gitter/Client.php on line 244

[wimrijnders]

Hey @khyox,

OK, delving deeper here. Let's see in how many ways the given exception can occur.

This exception happens during the refresh of the cached repository list. So it's not a stale cache problem. From the paths in the supplied stack trace, I gather that you're running on Linux.

Assuming that what you say is correct:

• root directory '/home/git/' is valid in system.ini.
• git repo's exist in the given root directory
• Read permission are ok for these git repo's. (If the owner of the git repo's is different from the owner of lighttpd, I am also assuming that o+r permission is set for the repo's).

Then the exception can occur if:

• All specified root directories are also specified as hidden in the config.ini.
• The git repo's all have a prefixed dot in the filename, as in '.i_am_hidden'.
• The execute permission of the root directory '/home/git/' is disabled.
• The execute permission on all git repo's is disabled.

So, would you mind checking if:

• The following line occurs in your config.ini:

  hidden[]= '/home/git'

... or perhaps even hidden[]= '/home'?

• On 'ls /home/git', do the repo names start with a dot?

• On 'ls -ld /home/git', do you see the x-es as in:

  drwxr-xr-x 9 wim wim 4096 apr 12 05:40 .

• On 'ls -l /home/git', do you see the x-es as in previous point?

That's about all situations I can find in this exhaustive search. I hope this is of some use.

Kind Regards,

Wim.

[khyox]

Hi Wim,

Thank you very much, indeed, for your commitment and exhaustive analysis of my problem.

I did not explain it well but when I wrote "I am suffering this issue only with the development build", I meant that I was not observing this trouble with the stable release, only with the development one. I must add that the config.ini file are the same for both (I just copied it) and also they have the same owner, group and permissions in their respective trees. Anyway, I checked your points and, unfortunately, none of them applies.

As this is happening with the development and not the stable one I was finally very biased to think that some software change could be in the origin. This was my first time looking at PHP code so, please, be indulgent with me if I do something stupid... I hope not!

Well, what I have done is compare Client.php between the 'stable' and 'development' releases. I checked that the error was thrown from the getRepositories() method in the 'development' release while it was not doing so from the same method in the 'stable' release although it was also executing this method.

But the method has been rewritten in the development's... Some excerpt before the point that throws the runtime exception:

public function getRepositories($paths)
{
    # If repo list already loaded, use that.
    $repos = $this->repositories;
    if ($repos == null) {
        # Try loading from cache
        $repos = $this->handleCached();
    }
    if ($repos != null) {
        ksort($repos);
        return $repos;
    }
    $repos = array();
    # If no paths specified, don't bother searching them
    if ($paths == null) return $repos;
    #
    # No cache file either, create repo list from scratch
    #
    if (!is_array($paths)) {
        $paths = array($paths);
    }
    foreach($paths  as $path) {
        # TODO: check what happens if multiple similar paths are merged.
        $this->recurseDirectory($repos, $path);
    }
    if (empty($repos)) {
        throw new \RuntimeException('There are no GIT repositories in ' . $path);
    }
    (...)
}

Well, it seems to me that if the repo list is not already loaded and if the cache is empty, then the $repos is initialized to an empty array. Then, if $path is not-null, it creates repo list from scratch using recurseDirectory()method (please, correct me if I am wrong with any supposition). But that method, recurseDirectory(), has also changed a lot from the stable to the development release.

I decided then to apply the most ancient form of debugging to recurseDirectory(). I am sure there are better methods… but taking into account my level of PHP and its framework (I mean the absence of it…), I felt comfortable using error_log() function and echo(), between lines.

I think the result is self-explanatory:

---

-> Entering recurseDirectory() in /home/git/ foreach filename is: .zshrc foreach filename is: .. foreach filename is: tuns.git __ Updates $recurse with /home/git/tuns.git foreach filename is: .bash_profile foreach filename is: .ssh foreach filename is: .mozilla foreach filename is: .bash_logout foreach filename is: .bashrc foreach filename is: .emacs foreach filename is: . foreach filename is: .bash_history foreach filename is: .gnome2 Ended foreach, next is the content of $recurse:Array ( [0] => /home/git/tuns.git ) Recursive call to recurseDirectory()... -> Entering recurseDirectory() in /home/git/tuns.git Not doing git directories!

---

I found that this behavior was due to the "Paranoia check; don't recurse into git directories", that was avoiding the "foreach ($dir as $file)" reaching the "." case. So, I moved that check to the end of the method, so that it is now:

private function recurseDirectory(&$repositories, $path)
{

(…)

    # Paranoia check; don't recurse into git directories
    if (self::endsWith($path, ".git") || self::endsWith($path, "HEAD")) {
        echo "Not doing git directories!\n";
        return;
    }

    foreach ($recurse as $item) {
        echo("<br /> Recursive call to recurseDirectory()... <br />");
        $this->recurseDirectory($repositories, $item);
    }
}

}

With this, at least, I finally avoid the 'There are no GIT repositories in /home/git/' runtime exception. Now, the recurse is performing well, because I get:

---

Entering recurseDirectory() in /home/git/ foreach filename is: .zshrc foreach filename is: .. foreach filename is: tuns.git __ Updates $recurse with /home/git/tuns.git foreach filename is: .bash_profile foreach filename is: .ssh foreach filename is: .mozilla foreach filename is: .bash_logout foreach filename is: .bashrc foreach filename is: .emacs foreach filename is: . foreach filename is: .bash_history foreach filename is: .gnome2 Ended foreach, next is the content of $recurse:Array ( [0] => /home/git/tuns.git ) Recursive call to recurseDirectory()... -> Entering recurseDirectory() in /home/git/tuns.git foreach filename is: branches Updates $recurse with /home/git/tuns.git/branches foreach filename is: description foreach filename is: hooks Updates $recurse with /home/git/tuns.git/hooks foreach filename is: refs Updates $recurse with /home/git/tuns.git/refs foreach filename is: .. foreach filename is: info Updates $recurse with /home/git/tuns.git/info foreach filename is: . foreach filename is: config foreach filename is: objects __ Updates $recurse with /home/git/tuns.git/objects foreach filename is: HEAD Ended foreach, next is the content of $recurse:Array ( [0] => /home/git/tuns.git/branches [1] => /home/git/tuns.git/hooks [2] => /home/git/tuns.git/refs [3] => /home/git/tuns.git/info [4] => /home/git/tuns.git/objects ) Updated content of $repositories:Array ( [tuns.git] => Array ( [name] => tuns.git [relativePath] => /home/git/tuns.git/. [path] => /home/git/tuns.git/. [description] => tuns library repository ) ) Not doing git directories!

---

Finally I get the gitlist interface with the "tuns" repo as with the stable release. Reloading again, the cache is present (because cache/repos.json file, I think) and the recurseDirectory() method is not executed and the issue is not appearing anymore even if I revert my changes in Client.php.

In any case, with this, I get that the repo is listed by gitlist development release BUT the link to the repo is not working: I mean, "http://X.Y.Z.T/gitlist_build/tuns.git/" gives "not found")… but this is a new problem and I have to find out if it is related with the workaround I introduced in the code, or not...

Thank you very much for your help and best regards. Jose

[wimrijnders]

Hi @khyox,

Wow, what an extensive post. You really went through a lot of trouble to understand the issue.

Yes, recurseDirectory() was rewritten quite a lot, and I know who the culprit was.....me :-(. I actually also discovered that problem in the meantime, please check #304. The 'paranoia check' has been rewritten to:

# Paranoia check; don't recurse into git directories
$base = basename($path);
 if ($base == ".git" || $base == "HEAD") {
    #echo "Not doing git directories!\n";
    return;
}

Since you were brave enough to delve into the code (I stand in awe, most don't go that far), perhaps you are willing to change this bit to see if it works for you. Your suppositions are entirely correct, by the way, which makes me happy despite the bug, since I apparently wrote code clear enough to be understood. And I also regularly resort to your method of bugfinding when I don't feel like firing up the debugger.

I took note of your code transplant, will also add it into the code.

There's a new development build coming up, this should solve many problems, including what you're describing. I'm waiting till that development build has been released before continuing fixing issues.

Thanks a lot for your participation, I find it motivating.

[khyox]

Hi Wim,

Sorry for the delay and than you very much for your answer! The 'paranoia check' so rewritten let me see the repository but I tried it where it was originally and where I 'transplanted' it and, in both cases, it does the recursion inside the git directory full depth. As I had active all such 'echo' lines, I could notice that the recursion is not stopping as expected (if I understood it well)... I can send you all the log if you think it could be useful.

I'll be looking forward the new development release as I could not go further testing, with the not-found repo link error that I described.

Thank you very much for your excellent commented code and very detailed info that you provide where in the web in the issues in which you are taking part!

[wimrijnders]

HI @khyox,

Thank you for the kind words! This kind of interaction is what makes me happy to work on open source projects.

The 'paranoia check' is intended to detect the .git directory, in which git stores the repo information. The check on 'HEAD' is to also make it work on bare repositories. So, the 'paranoia check' should prevent the recursion going into the .git directory.

However, the recursion should continue in the regular directories, in which the code is checked out. It is possible that these contain git repositories as well (gitlist itself is an example). So I'm wondering what you mean when you say that the recursion just continues: does the recursion continue in the checked out part (this is ok), or does it recurse into the .git part (this should not happen)?

Yes, if you don't mind, please send me the logs. I'd like to know what is going on.

[khyox]

Hi Wim,

Thank you very much for your fast and kind reply! I am glad to help with a microscopic grain of sand but… sand at the end! :-)

Well, I prepared a git server (via lighted) and I pushed only a project, 'tuns', so it is supposed to be a bare repository and only one.

I see that the recursion continues into the .git part. Here you are the 'log' where I cut some parts with (…) to help readability of the key info:

---

Entering recurseDirectory() in /home/git/ foreach filename is: .. foreach filename is: tuns.git Updates $recurse with /home/git/tuns.git foreach filename is: .ssh foreach filename is: . Ended foreach, next is the content of $recurse:Array ( [0] => /home/git/tuns.git ) Recursive call to recurseDirectory()... -> Entering recurseDirectory() in /home/git/tuns.git foreach filename is: branches Updates $recurse with /home/git/tuns.git/branches foreach filename is: description foreach filename is: hooks Updates $recurse with /home/git/tuns.git/hooks foreach filename is: refs Updates $recurse with /home/git/tuns.git/refs foreach filename is: .. foreach filename is: info Updates $recurse with /home/git/tuns.git/info foreach filename is: . foreach filename is: config foreach filename is: objects Updates $recurse with /home/git/tuns.git/objects foreach filename is: HEAD Ended foreach, next is the content of $recurse:Array ( [0] => /home/git/tuns.git/branches [1] => /home/git/tuns.git/hooks [2] => /home/git/tuns.git/refs [3] => /home/git/tuns.git/info [4] => /home/git/tuns.git/objects ) Updated content of $repositories:Array ( [tuns.git] => Array ( [name] => tuns.git [relativePath] => /home/git/tuns.git/. [path] => /home/git/tuns.git/. [description] => TUNS library repository ) ) Recursive call to recurseDirectory()... -> Entering recurseDirectory() in /home/git/tuns.git/branches foreach filename is: .. foreach filename is: . Ended foreach, next is the content of $recurse:Array ( ) Recursive call to recurseDirectory()... -> Entering recurseDirectory() in /home/git/tuns.git/hooks foreach filename is: applypatch-msg.sample foreach filename is: pre-applypatch.sample foreach filename is: post-commit.sample foreach filename is: post-update foreach filename is: pre-commit.sample foreach filename is: .. foreach filename is: update.sample foreach filename is: prepare-commit-msg.sample foreach filename is: commit-msg.sample foreach filename is: . foreach filename is: post-receive.sample foreach filename is: pre-rebase.sample Ended foreach, next is the content of $recurse:Array ( ) Recursive call to recurseDirectory()... -> Entering recurseDirectory() in /home/git/tuns.git/refs foreach filename is: tags Updates $recurse with /home/git/tuns.git/refs/tags foreach filename is: heads Updates $recurse with /home/git/tuns.git/refs/heads foreach filename is: .. foreach filename is: . Ended foreach, next is the content of $recurse:Array ( [0] => /home/git/tuns.git/refs/tags [1] => /home/git/tuns.git/refs/heads ) Recursive call to recurseDirectory()... -> Entering recurseDirectory() in /home/git/tuns.git/refs/tags foreach filename is: .. foreach filename is: . Ended foreach, next is the content of $recurse:Array ( ) Recursive call to recurseDirectory()... -> Entering recurseDirectory() in /home/git/tuns.git/refs/heads foreach filename is: master foreach filename is: .. foreach filename is: . Ended foreach, next is the content of $recurse:Array ( ) Recursive call to recurseDirectory()... -> Entering recurseDirectory() in /home/git/tuns.git/info foreach filename is: exclude foreach filename is: refs foreach filename is: .. foreach filename is: . Ended foreach, next is the content of $recurse:Array ( ) Recursive call to recurseDirectory()... -> Entering recurseDirectory() in /home/git/tuns.git/objects foreach filename is: 28 Updates $recurse with /home/git/tuns.git/objects/28 (…) foreach filename is: 7e Updates $recurse with /home/git/tuns.git/objects/7e foreach filename is: pack Updates $recurse with /home/git/tuns.git/objects/pack foreach filename is: d6 Updates $recurse with /home/git/tuns.git/objects/d6 (…) foreach filename is: 62 Updates $recurse with /home/git/tuns.git/objects/62 foreach filename is: . foreach filename is: ed Updates $recurse with /home/git/tuns.git/objects/ed (…) foreach filename is: 2f __ Updates $recurse with /home/git/tuns.git/objects/2f Ended foreach, next is the content of $recurse:Array ( [0] => /home/git/tuns.git/objects/28 [1] => /home/git/tuns.git/objects/e6 [2] => /home/git/tuns.git/objects/db [3] => /home/git/tuns.git/objects/27 [4] => /home/git/tuns.git/objects/1e [5] => /home/git/tuns.git/objects/40 [6] => /home/git/tuns.git/objects/3d [7] => /home/git/tuns.git/objects/7e [8] => /home/git/tuns.git/objects/pack [9] => /home/git/tuns.git/objects/d6 [10] => /home/git/tuns.git/objects/b4 [11] => /home/git/tuns.git/objects/34 [12] => /home/git/tuns.git/objects/f9 [13] => /home/git/tuns.git/objects/b2 [14] => /home/git/tuns.git/objects/8c [15] => /home/git/tuns.git/objects/e2 [16] => /home/git/tuns.git/objects/info [17] => /home/git/tuns.git/objects/ac [18] => /home/git/tuns.git/objects/c7 [19] => /home/git/tuns.git/objects/ee [20] => /home/git/tuns.git/objects/47 [21] => /home/git/tuns.git/objects/9c [22] => /home/git/tuns.git/objects/0f [23] => /home/git/tuns.git/objects/c0 [24] => /home/git/tuns.git/objects/30 [25] => /home/git/tuns.git/objects/cb [26] => /home/git/tuns.git/objects/bf [27] => /home/git/tuns.git/objects/c2 [28] => /home/git/tuns.git/objects/81 [29] => /home/git/tuns.git/objects/bd [30] => /home/git/tuns.git/objects/9a [31] => /home/git/tuns.git/objects/ef [32] => /home/git/tuns.git/objects/17 [33] => /home/git/tuns.git/objects/fc [34] => /home/git/tuns.git/objects/62 [35] => /home/git/tuns.git/objects/ed [36] => /home/git/tuns.git/objects/64 [37] => /home/git/tuns.git/objects/8e [38] => /home/git/tuns.git/objects/67 [39] => /home/git/tuns.git/objects/52 [40] => /home/git/tuns.git/objects/72 [41] => /home/git/tuns.git/objects/77 [42] => /home/git/tuns.git/objects/86 [43] => /home/git/tuns.git/objects/2f ) Recursive call to recurseDirectory()... -> Entering recurseDirectory() in /home/git/tuns.git/objects/28 foreach filename is: .. foreach filename is: 9867e5068cc877185767f2a9fd3a62fe8280f6 foreach filename is: . Ended foreach, next is the content of $recurse:Array ( ) (…) Recursive call to recurseDirectory()... -> Entering recurseDirectory() in /home/git/tuns.git/objects/7e foreach filename is: .. foreach filename is: 696f6a202a5587225ed5e35bef60177df3a5e6 foreach filename is: . Ended foreach, next is the content of $recurse:Array ( ) Recursive call to recurseDirectory()... -> Entering recurseDirectory() in /home/git/tuns.git/objects/pack foreach filename is: pack-cdfb55e23374608da9276b7dc27149537a377e73.idx foreach filename is: pack-08544c4fc6dafe97d76fa7d30bdc69fb021c357d.pack foreach filename is: .. foreach filename is: pack-539613b6194cca2641c60ce328078190baf38762.pack foreach filename is: pack-08544c4fc6dafe97d76fa7d30bdc69fb021c357d.idx foreach filename is: . foreach filename is: pack-cdfb55e23374608da9276b7dc27149537a377e73.pack foreach filename is: pack-539613b6194cca2641c60ce328078190baf38762.idx Ended foreach, next is the content of $recurse:Array ( ) Recursive call to recurseDirectory()... -> Entering recurseDirectory() in /home/git/tuns.git/objects/d6 foreach filename is: .. foreach filename is: 77d2889e8be65e306b2cb082f2c31af5601ed6 foreach filename is: . Ended foreach, next is the content of $recurse:Array ( ) (…) Recursive call to recurseDirectory()... -> Entering recurseDirectory() in /home/git/tuns.git/objects/2f foreach filename is: .. foreach filename is: 24da589e4c2ebc7c5c6484021c64e4e015f6f6 foreach filename is: . Ended foreach, next is the content of $recurse:Array ( )

---

Thanks and kind regards!

[wimrijnders]

@khyox,

Ok the log was useful. I looked into it and discovered that bare repo's were not handled correctly in recurseDirectory() . The logic was flawed, so I rewrote the method. In my environment it now functions fine. Bare repo's are picked up correctly, and also .git's are not recursed into any more.

If you care to test, get the code from here: https://github.com/klaussilveira/gitter/blob/master/lib/Gitter/Client.php. Copy the entire method recurseDirectory() over your current one.

Kind regards,

Wim.

[khyox]

Hi Wim,

Waw! I tested it and now it's all right! Good job indeed!

---

-> Entering recurseDirectory() in /home/git/ foreach filename is: .. foreach filename is: tuns.git __ Updates $recurse with /home/git/tuns.git foreach filename is: .ssh foreach filename is: . Ended foreach, next is the content of $recurse: array(1) { [0]=> string(18) "/home/git/tuns.git" } -> Entering recurseDirectory() in /home/git/tuns.git Updated content of $repositories: Array ( [tuns.git] => Array ( [name] => tuns.git [relativePath] => /home/git/tuns.git [path] => /home/git/tuns.git [description] => TUNS library repository ) )

---

Thank you very much and kind regards.

[wimrijnders]

High Five!

@klaussilveira: Can this issue be closed now? Or does someone need to verify this?

Very pleasant working with you!

Kind Regards,

Wim.

[khyox]

Hi again Wim! This issue is still alive. You committed the changes to Gitter but the composer.lock of Gitlist is not updated. To sum up, composer.lock now begins with:

{
    "hash": "e1fd62caf104a8cbb216cdb0aa2fe317",
    "packages": [
        {
            "name": "klaussilveira/gitter",
            "version": "dev-master",
            "source": {
                "type": "git",
                "url": "https://github.com/klaussilveira/gitter.git",
                "reference": "47c7aba9465c22595e7424ba989631aa80ccbea0"
            },
            "dist": {
                "type": "zip",
                "url": "https://api.github.com/repos/klaussilveira/gitter/zipball/47c7aba9465c22595e7424ba98\
9631aa80ccbea0",
                "reference": "47c7aba9465c22595e7424ba989631aa80ccbea0",
                "shasum": ""
            },

And it should be:

    "packages": [
        {
            "name": "klaussilveira/gitter",
            "version": "dev-master",
            "source": {
                "type": "git",
                "url": "https://github.com/klaussilveira/gitter.git",
                "reference": "084dbe567d07a25ca04378782afffee7d6bb3b88"
            },
            "dist": {
                "type": "zip",
                "url": "https://api.github.com/repos/klaussilveira/gitter/zipball/084dbe567d07a25ca04378782afffee7d6bb3b88",
                "reference": "084dbe567d07a25ca04378782afffee7d6bb3b88",
                "shasum": ""
            },

With this corrected, now:

[gitlist_base_dir]$ php composer.phar install
Loading composer repositories with package information
Installing dependencies from lock file
  - Updating klaussilveira/gitter dev-master (47c7aba => 084dbe5)
    Checking out 084dbe567d07a25ca04378782afffee7d6bb3b88

And the problem disappears in a totally new clone installation! Hope this helps. :)

[wimrijnders]

Hi @khyox,

Thanks for spotting this. I fully admit my ignorance of composer and its usage, and I appreciate your efforts to fix this.

Is this something that needs to be checked in still, or have done this already?

[khyox]

Hi Wim,

Not at all! My ignorance of composer is even worse for sure... I just traced the problem to that file. Just changing that seems to be enough for the problem to be solved even for a fresh clone of the master branch, but I don't know if the line "hash": "e1fd62caf104a8cbb216cdb0aa2fe317", should be better updated as the contents of the file have changed.