There are a few ways this can occur:
Key = *http.sslVerify* Value = *false*
Please check server.httpBindInterface and server.httpsBindInterface in gitblit.properties, you may be binding only to localhost.
And of course ensure that any firewall you may have running either has an exception for your ports or for the running process.
Linux requires root permissions to serve on ports < 1024.
Run the server as root (security concern) or change the ports you are serving to 8080 (http) and/or 8443 (https).
Confirm that the value git.repositoriesFolder in gitblit.properties actually points to your repositories folder.
Confirm that the <context-param> git.repositoriesFolder value in your web.xml file actually points to your repositories folder.
Confirm that the <context-param> realm.userService value in your web.xml file actually points to a users.properties file.
It's a phonetic play on bitblt which is an image processing operation meaning bit-block transfer.
It's a small tool that allows you to easily manage shared repositories and doesn't require alot of setup or git kung-foo.
Small workgroups that require centralized repositories.
Gitblit is not meant to be a social coding resource like Github or Bitbucket with 100s or 1000s of users. Gitblit is designed to fulfill the same function as your centralized Subversion or CVS server.
As a Java developer I prefer that as much of my tooling as possible is Java.
Originally, I was going to use Mercurial but...
Gitblit eliminates all that complication with its 100% Java stack and simple single configuration file.
Additionally, Git and Gitweb do not offer repository creation or user management.
No. Gitblit is based on JGit which is a pure Java implementation of the Git version control system.
Everything you need for Gitblit (except Java) is either bundled in the distribution file or automatically downloaded on execution.
Yes.
Gitblit will run just fine with a JRE. Gitblit can optionally use keytool from the JDK to generate self-signed certificates, but normally Gitblit uses BouncyCastle for that need.
No. Gitblit stores its repository configuration information within the .git/config file and its user information in users.properties or whatever filename is configured in gitblit.properties.
Yes. You can manually manipulate all of them and (most) changes will be immediately available to Gitblit.
Exceptions to this are noted in gitblit.properties.
NOTE: Care must be taken to preserve the relationship between user roles and repository names.
Please see the User Roles section of the setup page for details.
No. Access restrictions apply to the repository as a whole.
Gitblit's simple authentication and authorization mechanism can be used to facilitate one or more of the workflows outlined here. Should you require more fine-grained access controls you might consider using gitolite.
Yes. The user service is pluggable. You may write your own user service by implementing the com.gitblit.IUserService interface. Set the fully qualified classname as the realm.userService property.
Gitblit could integrate Apache Mina to provide SSH access. However, doing so violates Gitblit's first design principle: KISS.
SSH support requires creating, exchanging, and managing SSH keys (arguably not more complicated than managing users). While this is possible, JGit's SmartHTTP implementation is a simpler and universal transport mechanism.
You might consider running Gerrit which does integrate Apache Mina and supports SSH or you might consider serving Git on Linux which would offer real SSH support and also allow use of many other compelling Git solutions.
Gitblit supports case-insensitive searches of commit message (default), author, and committer.
To search by author or committer use the following syntax in the search box:
author: james
committer: james
Alternatively, you could enable the search type dropdown list in your gitblit.properties file.
Yes. Most messages are localized to a standard Java properties file.