| | |
| | | 1. You are using https with a self-signed certificate and you **did not** configure *http.sslVerify=false*
|
| | | 1. Window->Preferences->Team->Git->Configuration
|
| | | 2. Click the *New Entry* button
|
| | | 3. <pre>Key = *http.sslVerify* |
| | | Value = *false*</pre>
|
| | | 3. <pre>Key = <em>http.sslVerify</em>
|
| | | Value = <em>false</em></pre>
|
| | | 2. Gitblit GO's default self-signed certificate is bound to *localhost* and you are trying to clone/push between machines.
|
| | | 1. Review the contents of `makekeystore.cmd`
|
| | | 2. Set *your hostname* in the *HOSTNAME* variable.
|
| | |
| | | 2. Confirm that the servlet container process has full read-write-execute permissions to your *git.repositoriesFolder*.
|
| | |
|
| | | ### Gitblit WAR will not authenticate any users?!
|
| | | Confirm that the <context-param> *realm.userService* value in your `web.xml` file actually points to a `users.properties` file.
|
| | | Confirm that the <context-param> *realm.userService* value in your `web.xml` file actually points to a `users.conf` or `users.properties` file.
|
| | |
|
| | | ### Gitblit won't open my grouped repository (/group/myrepo.git) or browse my branch/tag/ref?!
|
| | | This is likely an url encoding/decoding problem related to your servlet container's security. There are two possible workarounds for this issue. In `gitblit.properties` or `web.xml`:
|
| | | ### Gitblit won't open my grouped repository (/group/myrepo.git) or browse my log/branch/tag/ref?!
|
| | | 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`:
|
| | |
|
| | | 1. try setting *web.mountParameters* to *false*.<br/>This changes the url scheme from mounted (*/commit/myrepo.git/abcdef*) to parameterized (*/commit/?r=myrepo.git&h=abcdef*).
|
| | | 2. try changing *web.forwardSlashCharacter* to an asterisk or a **!**
|
| | |
|
| | | ### Running Gitblit behind mod_proxy or some other proxy layer
|
| | |
|
| | | 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](http://httpd.apache.org/docs/2.2/mod/core.html#allowencodedslashes).
|
| | |
|
| | | ### Running Gitblit on Tomcat
|
| | |
|
| | | Tomcat takes the extra precaution of [disallowing embedded slashes by default](http://tomcat.apache.org/security-6.html#Fixed_in_Apache_Tomcat_6.0.10). This breaks Gitblit urls. |
| | | You have a few options on how to handle this scenario:
|
| | |
|
| | | 1. [Tweak Tomcat](http://tomcat.apache.org/security-6.html#Fixed_in_Apache_Tomcat_6.0.10) |
| | | Add *org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true* to *CATALINA_OPTS*
|
| | | 2. *web.mountParameters = false* and use non-pretty, parameterized urls
|
| | | 3. *web.forwardSlashCharacter = !* which tells Gitblit to use **!** instead of **/**
|
| | |
|
| | | ## General Interest Questions
|
| | |
|
| | |
| | | No (mostly). Gitblit is based on [JGit][jgit] which is a pure Java implementation of the [Git version control system][git].<br/>
|
| | | Everything you need for Gitblit (except Java) is either bundled in the distribution file or automatically downloaded on execution.
|
| | |
|
| | | **mostly**<br/>
|
| | | #### mostly
|
| | | JGit does not fully support the git-gc featureset (garbage collection) so you may want native Git to periodically run git-gc until [JGit][jgit] fully supports this feature.
|
| | |
|
| | | ### Can I run Gitblit in conjunction with my existing Git tooling?
|
| | |
| | | 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][bouncycastle] for that need.
|
| | |
|
| | | ### Does Gitblit use a database to store its data?
|
| | | 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`.
|
| | | 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`.
|
| | |
|
| | | ### Can I manually edit users.properties, gitblit.properties, or .git/config?
|
| | | ### Can I manually edit users.conf, users.properties, gitblit.properties, or .git/config?
|
| | | Yes. You can manually manipulate all of them and (most) changes will be immediately available to Gitblit.<br/>Exceptions to this are noted in `gitblit.properties`.
|
| | |
|
| | | **NOTE:**<br/>Care must be taken to preserve the relationship between user roles and repository names.<br/>Please see the *User Roles* section of the [setup](/setup.html) page for details.
|
| | | **NOTE:** |
| | | Care must be taken to preserve the relationship between user roles and repository names.<br/>Please see the *User Roles* section of the [setup](/setup.html) page for details.
|
| | |
|
| | | ### Can I restrict access to paths within a repository?
|
| | | No. Access restrictions apply to the repository as a whole.
|
| | | ### Can I restrict access to branches or paths within a repository?
|
| | | No, not out-of-the-box. 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](http://progit.org/book/ch5-1.html). Should you require more fine-grained access controls you might consider using [gitolite](https://github.com/sitaramc/gitolite).
|
| | | Gitblit's simple authentication and authorization mechanism can be used to facilitate one or more of the [workflows outlined here](http://progit.org/book/ch5-1.html).
|
| | |
|
| | | 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](https://github.com/sitaramc/gitolite) and SSH for your repository access.
|
| | |
|
| | | ### Can I authenticate users against XYZ?
|
| | | 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.
|
| | | 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.
|
| | |
|
| | | ### Why doesn't Gitblit support SSH?
|
| | | Gitblit could integrate [Apache Mina][mina] to provide SSH access. However, doing so violates Gitblit's first design principle: [KISS](http://en.wikipedia.org/wiki/KISS_principle).<br/>
|