Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No repositories causes RuntimeException #195

Closed
uuf6429 opened this issue Oct 23, 2012 · 19 comments
Closed

No repositories causes RuntimeException #195

uuf6429 opened this issue Oct 23, 2012 · 19 comments
Labels

Comments

@uuf6429
Copy link

uuf6429 commented Oct 23, 2012

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
Copy link

ArvinB commented Feb 17, 2013

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
Copy link
Owner

We will check for read permissions on the next version.

@uuf6429
Copy link
Author

uuf6429 commented Feb 19, 2013

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
Copy link

ArvinB commented Feb 19, 2013

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
#195 (comment)
.

@khyox
Copy link

khyox commented Apr 11, 2013

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
Copy link
Collaborator

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
Copy link

khyox commented Apr 11, 2013

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
Copy link
Collaborator

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
Copy link

khyox commented Apr 12, 2013

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
Copy link
Collaborator

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
Copy link

khyox commented Apr 17, 2013

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
Copy link
Collaborator

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
Copy link

khyox commented Apr 17, 2013

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
Copy link
Collaborator

@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
Copy link

khyox commented Apr 18, 2013

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
Copy link
Collaborator

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
Copy link

khyox commented May 17, 2013

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
Copy link
Collaborator

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
Copy link

khyox commented May 17, 2013

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants