This is a bug in JGit (issue 704). TLDR: Newer git clients are optimized to send less data on the wire. JGit expects complete data to be sent, but there are scenarios where native git can optimize-out sending objects. By default, JGit requires everything sent be complete and referenceable.
If you experience this, the workaround is to temporarily disable the reachable check for the receive pack, push, and then re-enable the setting.
git.checkReferencedObjectsAreReachable = false
There are a few ways this can occur:
Key = http.sslVerify Value = false
This is a long-standing, known bug in the native Git for Windows implementation.
Please see this thread for details.
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.propertiesactually points to your repositories folder.
This is likely an url encoding/decoding problem with forward slashes:
You can not trust the url in the address bar of your browser since your browser may decode it for presentation. When in doubt, View Source of the generated html to confirm the href.
There are two possible workarounds for this issue. In
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 you may have luck with specifying 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:
Tomcat also dislikes urls with non-ASCII characters. If your repositories have non-ASCII filenames you will have to modify your connector properties to allow UTF-8 encoded urls.
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.
Gitblit has experimental support for Garbage Collection using JGit. I have not used it enough to feel comfortable removing the EXPERIMENTAL label. It may work really well, or it may not. One thing you might consider having native git for is periodic garbage collection - when Gitblit is offline.
Gitblit will run just fine with a JRE.
No. Gitblit stores its repository configuration information within the
.git/config file and its user information in
users.conf or whatever filename is configured in
Yes. You can manually manipulate all of them and (most) changes will be immediately available to Gitblit.
Exceptions to this are noted in
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, not yet. 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 writing a Groovy prereceive script to block updating branch refs based on some permissions file. I would be interested in a generic, re-usable script to include with Gitblit, should someone want to implement it.
Alternatively, you could use gitolite and SSH for your repository access.
Yes. The user service is pluggable. You may write your own complete user service by implementing the com.gitblit.IUserService interface. Or you may subclass com.gitblit.GitblitUserService and override just the authentication. Set the fully qualified classname as the realm.userService property.
As of 0.9.0, Gitblit supports Lucene-based searching.
If Lucene indexing is disabled, Gitblit falls back to brute-force commit-traversal search. Commit-traversal search supports case-insensitive searching 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
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.