There are a few ways this can occur:
Key = http.sslVerify Value = false
makekeystore.cmd
gitblit.properties
, you may be only be serving on localhost.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).
gitblit.properties
actually points to your repositories folder.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.conf
or users.properties
file.
This is likely an url encoding/decoding problem with forward slashes:
bad
http://192.168.1.2/log/myrepo.git/refs/heads/master
good
http://192.168.1.2/log/myrepo.git/refs%2Fheads%2Fmaster
NOTE:
You can not trust the url in the address bar of your browser since your browser may prettify the url. When in doubt, View Source of the generated html to confirm the href.
There are two possible workarounds for this issue. In gitblit.properties
or web.xml
:
You must ensure that the proxy does not decode and then re-encode request urls with interpretation of forward-slashes (*%2F*). If your proxy layer does re-encode embedded forward-slashes then you may not be able to browse grouped repositories or logs, branches, and tags unless you set web.mountParameters=false.
If you are using Apache mod_proxy, specify AllowEncodedSlashes NoDecode.
Tomcat takes the extra precaution of disallowing embedded slashes by default. This breaks Gitblit urls.
You have a few options on how to handle this scenario:
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 (mostly). 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.
JGit does not fully support the git-gc featureset (garbage collection) so you may want native Git to periodically run git-gc until JGit fully supports this feature.
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.conf
, 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, yes I know that you are really specifying the period, but Frequency sounds better to me. :)
Yes. Most messages are localized to a standard Java properties file.