| | |
|---|
| | | ## Gitblit WAR Installation & Setup
|
|---|
| | |
|
|---|
| | | 1. Download [Gitblit WAR ${project.releaseVersion}](%GCURL%gitblit-${project.releaseVersion}.war) to the webapps folder of your servlet container. |
|---|
| | | 2. You may have to manually extract the WAR (zip file) to a folder within your webapps folder.
|
|---|
| | | 3. By default, the Gitblit webapp is configured through `WEB-INF/data/gitblit.properties`.<br/>
|
|---|
| | | Open `WEB-INF/data/gitblit.properties` in your favorite text editor and make sure to review and set:
|
|---|
| | | - <context-parameter> *git.packedGitLimit* (set larger than the size of your largest repository)
|
|---|
| | | - <context-parameter> *git.streamFileThreshold* (set larger than the size of your largest committed file)
|
|---|
| | | 4. You may have to restart your servlet container. |
|---|
| | | 5. Open your browser to <http://localhost/gitblit> or whatever the url should be.
|
|---|
| | | 6. Enter the default administrator credentials: **admin / admin** and click the *Login* button |
|---|
| | | **NOTE:** Make sure to change the administrator username and/or password!! |
|---|
| | |
|
|---|
| | | ### WAR Data Location
|
|---|
| | | By default, Gitblit WAR stores all data (users, settings, repositories, etc) in `${contextFolder}/WEB-INF/data`. This is fine for a quick setup, but there are many reasons why you don't want to keep your data within the webapps folder of your servlet container. You may specify an external location for your data by editing `WEB-INF/web.xml` and manipulating the *baseFolder* context parameter. Choose a location that is writeable by your servlet container. Your servlet container may be smart enough to recognize the change and to restart Gitblit.
|
|---|
| | |
|
|---|
| | | On the next restart of Gitblit, Gitblit will copy the contents of the `WEB-INF/data` folder to your specified *baseFolder* **IF** the file `${baseFolder}/gitblit.properties` does not already exist. This allows you to get going with minimal fuss.
|
|---|
| | |
|
|---|
| | | Specifying an alternate *baseFolder* also allows for simpler upgrades in the future.
|
|---|
| | |
|
|---|
| | | ## Gitblit GO Installation & Setup
|
|---|
| | |
|
|---|
| | | 1. Download and unzip [Gitblit GO ${project.releaseVersion}](%GCURL%gitblit-${project.releaseVersion}.zip). |
|---|
| | | *Its best to eliminate spaces in the path name.* |
|---|
| | | 2. The server itself is configured through a simple text file.<br/>
|
|---|
| | | Open `data/gitblit.properties` in your favorite text editor and make sure to review and set:
|
|---|
| | | - *server.httpPort* and *server.httpsPort*
|
|---|
| | | - *server.httpBindInterface* and *server.httpsBindInterface* |
|---|
| | | - *server.storePassword*
|
|---|
| | | **https** is strongly recommended because passwords are insecurely transmitted form your browser/git client using Basic authentication!
|
|---|
| | | - *git.packedGitLimit* (set larger than the size of your largest repository)
|
|---|
| | | - *git.streamFileThreshold* (set larger than the size of your largest committed file)
|
|---|
| | | 3. Execute `authority.cmd` or `java -cp gitblit.jar com.gitblit.authority.Launcher --baseFolder data` from a command-line
|
|---|
| | | 1. fill out the fields in the *new certificate defaults* dialog
|
|---|
| | | 2. enter the store password used in *server.storePassword* when prompted. This generates an SSL certificate for **localhost**.
|
|---|
| | | 3. you may want to generate an SSL certificate for the hostname or ip address hostnames you are serving from<br/>**NOTE:** You can only have **one** SSL certificate specified for a port.
|
|---|
| | | 5. exit the authority app
|
|---|
| | | 4. Execute `gitblit.cmd` or `java -jar gitblit.jar --baseFolder data` from a command-line
|
|---|
| | | 5. Open your browser to <http://localhost:8080> or <https://localhost:8443> depending on your chosen configuration.
|
|---|
| | | 6. Enter the default administrator credentials: **admin / admin** and click the *Login* button |
|---|
| | | **NOTE:** Make sure to change the administrator username and/or password!! |
|---|
| | |
|
|---|
| | | ### GO Data Location
|
|---|
| | |
|
|---|
| | | By default, Gitblit GO stores all data (users, settings, repositories, etc) in the `data` subfolder of your GO installation. You may specify an external location for your data on the command-line by setting the *--baseFolder* argument. If you relocate the data folder then you must supply the *--baseFolder* argument to both GO and the Certificate Authority.
|
|---|
| | |
|
|---|
| | | If you are deploying Gitblit to a *nix platform, you might consider moving the data folder out of the GO installation folder and then creating a symlink named "data" that points to your moved folder.
|
|---|
| | |
|
|---|
| | | ### Creating your own Self-Signed SSL Certificate
|
|---|
| | | Gitblit GO (and Gitblit Certificate Authority) automatically generates a Certificate Authority (CA) certificate and an ssl certificate signed by this CA certificate that is bound to *localhost*.
|
|---|
| | |
|
|---|
| | | Remote Eclipse/EGit/JGit clients (< 3.0) will fail to communicate using this certificate because JGit always verifies the hostname of the certificate, regardless of the *http.sslVerify=false* client-side setting.
|
|---|
| | |
|
|---|
| | | The EGit failure message is something like:
|
|---|
| | |
|
|---|
| | | Cannot get remote repository refs.
|
|---|
| | | Reason: https:/myserver.com/git/myrepo.git: cannot open git-upload-pack
|
|---|
| | |
|
|---|
| | | If you want to serve your repositories to another machine over https then you will want to generate a new certificate for the hostname or ip address you are serving from.
|
|---|
| | |
|
|---|
| | | 1. `authority.cmd` or `java -jar authority.jar --baseFolder data`
|
|---|
| | | 2. Click the *new ssl certificate* button (red rosette in the toolbar in upper left of window)
|
|---|
| | | 3. Enter the hostname or ip address
|
|---|
| | | 4. Make sure the checkbox *serve https with this certificate* is checked
|
|---|
| | | 5. In the keystore password prompt, enter the *server.storePassword* password
|
|---|
| | | |
|---|
| | | If you decide to change the value of *server.storePassword* (recommended) <u>after</u> you have already started Gitblit or Gitblit Certificate Authority, then you will have to delete the following files and then restart the Gitblit Certificate Authority app:
|
|---|
| | |
|
|---|
| | | 1. data/serverKeyStore.jks
|
|---|
| | | 2. data/serverTrustStore.jks
|
|---|
| | | 3. data/certs/caKeyStore.jks
|
|---|
| | | 4. data/certs/ca.crt
|
|---|
| | | 5. data/certs/caRevocationList.crl (optional)
|
|---|
| | |
|
|---|
| | | ### Client SSL Certificates
|
|---|
| | | SINCE 1.2.0
|
|---|
| | |
|
|---|
| | | Gitblit supports X509 certificate authentication. This authentication method relies on your servlet container to validate/verify/trust your client certificate and can be used by your browser and your git client.
|
|---|
| | |
|
|---|
| | | All X509 certificates have a *distinguished name (DN)* which is a signature of several fields like:
|
|---|
| | |
|
|---|
| | | C=US,O=Gitblit,OU=Gitblit,CN=james
|
|---|
| | | |
|---|
| | | Gitblit must be able to map the DN of the certificate to an *existing* account username. The default mapping is to extract the *common name (CN)* value from the DN and use that as the account name. If the CN is a valid account, then the user is authenticated. The servlet container which runs Gitblit validates, verifies, and trusts the certificate passed to Gitblit. If you need to specify an alternative DN mapping you may do so with the *git.certificateUsernameOIDs* setting, but this mapping must be matched to the user account name.
|
|---|
| | |
|
|---|
| | | How do you make your servlet container trust a client certificate?
|
|---|
| | |
|
|---|
| | | In the WAR variant, you will have to manually setup your servlet container to:
|
|---|
| | |
|
|---|
| | | 1. want/need client certificates
|
|---|
| | | 2. trust a CA certificate used to sign your client certificates
|
|---|
| | | 3. generate client certificates signed by your CA certificate
|
|---|
| | |
|
|---|
| | | Alternatively, Gitblit GO is designed to facilitate use of client certificate authentication. Gitblit GO ships with a tool that simplifies creation and management of client certificates, Gitblit Certificate Authority.
|
|---|
| | |
|
|---|
| | | #### Creating SSL Certificates with Gitblit Certificate Authority
|
|---|
| | |
|
|---|
| | | When you generate a new client certificate, a zip file bundle is created which includes a P12 keystore for browsers and a PEM keystore for Git. Both of these are password-protected. Additionally, a personalized README file is generated with setup instructions for popular browsers and Git. The README is generated from `data\certs\instructions.tmpl` and can be modified to suit your needs.
|
|---|
| | |
|
|---|
| | | 1. `authority.cmd` or `java -jar authority.jar --baseFolder data`
|
|---|
| | | 2. Select the user for which to generate the certificate
|
|---|
| | | 3. Click the *new certificate* button and enter the expiration date of the certificate. You must also enter a password for the generated keystore. This password is *not* the same as the user's login password. This password is used to protect the privatekey and public certificate you will generate for the selected user. You must also enter a password hint for the user.
|
|---|
| | | 4. If your mail server settings are properly configured you will have a *send email* checkbox which you can use to immediately send the generated certificate bundle to the user.
|
|---|
| | |
|
|---|
| | | #### Certificate Inspection and Advanced Troubleshooting
|
|---|
| | |
|
|---|
| | | X509 certificates can be confusing and tricky even with the simplified Gitblit Certificate Authority tool. If you find you need more tooling to understand your keystores, certificates, and certificate revocation lists (CRLs), I highly recommend [Portecle](http://portecle.sourceforge.net) which can be conveniently launched as a [Java Web Start app](http://portecle.sourceforge.net/webstart/portecle.jnlp).
|
|---|
| | |
|
|---|
| | | ### Running as a Windows Service
|
|---|
| | | Gitblit uses [Apache Commons Daemon](http://commons.apache.org/daemon) to install and configure its Windows service.
|
|---|
| | |
|
|---|
| | | 1. **Review the contents** of the `installService.cmd` where you may have to change the <u>default keystore password</u>.
|
|---|
| | | 2. Set the *ARCH* value as appropriate for your installed Java Virtual Machine.
|
|---|
| | | 3. Add any necessary *--StartParams* as enumerated below in **Command-Line Parameters**.
|
|---|
| | | 4. Execute the script.
|
|---|
| | |
|
|---|
| | | After service installation you can use the `gitblitw.exe` utility to control and modify the runtime settings of the service.<br/>
|
|---|
| | | Additional service definition options and runtime capabilities of `gitblitw.exe` (prunmgr.exe) are documented [here](http://commons.apache.org/daemon/procrun.html).
|
|---|
| | |
|
|---|
| | | **NOTE:**<br/>
|
|---|
| | | If you change the name of the service from *gitblit* you must also change the name of `gitblitw.exe` to match the new service name otherwise the connection between the service and the utility is lost, at least to double-click execution. |
|---|
| | |
|
|---|
| | | #### VM Considerations
|
|---|
| | | By default, the service installation script configures your Windows service to use your default JVM. This setup usually defaults to a client VM.<br/>
|
|---|
| | | If you have installed a JDK, you might consider using the `gitblitw.exe` utility to manually specify the *server* VM.
|
|---|
| | |
|
|---|
| | | 1. Execute `gitblitw.exe`
|
|---|
| | | 2. On the *Java* tab uncheck *Use default*.
|
|---|
| | | 3. Manually navigate your filesystem and specify the server VM with the `...` button<br/><pre>
|
|---|
| | | Java Virtual Machine:
|
|---|
| | | C:\Program Files\Java\jre6\bin\server\jvm.dll</pre>
|
|---|
| | |
|
|---|
| | | #### Command-Line Parameters
|
|---|
| | | Command-Line parameters override the values in `gitblit.properties` at runtime.
|
|---|
| | |
|
|---|
| | | --baseFolder The default base folder for all relative file reference settings
|
|---|
| | | --repositoriesFolder Git Repositories Folder
|
|---|
| | | --userService Authentication and Authorization Service (filename or fully qualified classname)
|
|---|
| | | --useNio Use NIO Connector else use Socket Connector.
|
|---|
| | | --httpPort HTTP port for to serve. (port <= 0 will disable this connector)
|
|---|
| | | --httpsPort HTTPS port to serve. (port <= 0 will disable this connector)
|
|---|
| | | --ajpPort AJP port to serve. (port <= 0 will disable this connector)
|
|---|
| | | --alias Alias in keystore of SSL cert to use for https serving
|
|---|
| | | --storePassword Password for SSL (https) keystore.
|
|---|
| | | --shutdownPort Port for Shutdown Monitor to listen on. (port <= 0 will disable this monitor)
|
|---|
| | | --tempFolder Folder for server to extract built-in webapp
|
|---|
| | | |
|---|
| | | **Example**
|
|---|
| | |
|
|---|
| | | java -jar gitblit.jar --userService c:/myrealm.config --storePassword something --baseFolder c:/data
|
|---|
| | |
|
|---|
| | | #### Overriding Gitblit GO's Log4j Configuration
|
|---|
| | |
|
|---|
| | | You can override Gitblit GO's default Log4j configuration with a command-line parameter to the JVM.
|
|---|
| | |
|
|---|
| | | java -Dlog4j.configuration=file:///home/james/log4j.properties -jar gitblit.jar <optional_gitblit_args>
|
|---|
| | | |
|---|
| | | For reference, here is [Gitblit's default Log4j configuration](https://github.com/gitblit/gitblit/blob/master/src/log4j.properties). It includes some file appenders that are disabled by default. |
|---|
| | | |
|---|
| | | ## Running Gitblit behind Apache
|
|---|
| | |
|
|---|
| | | Gitblit runs fine behind Apache. You may use either *mod_proxy* (GO or WAR) or *mod_proxy_ajp* (GO).
|
|---|
| | |
|
|---|
| | | Each Linux distribution may vary on the exact configuration of Apache 2.2. |
|---|
| | | Here is a sample configuration that works on Debian 7.0 (Wheezy), your distribution may be different.
|
|---|
| | |
|
|---|
| | | 1. First we need to make sure we have Apache's proxy modules available. |
|---|
| | | ---FIXED---
|
|---|
| | | sudo su
|
|---|
| | | cd /etc/apache2/mods-enabled
|
|---|
| | | ln -s ../mods-available/proxy.load proxy.load
|
|---|
| | | ln -s ../mods-available/proxy_balancer.load proxy_balancer.load
|
|---|
| | | ln -s ../mods-available/proxy_http.load proxy_http.load
|
|---|
| | | ln -s ../mods-available/proxy_ajp.load proxy_ajp.load
|
|---|
| | | ---FIXED---
|
|---|
| | | 2. Then we need to make sure we are configuring Apache to use the proxy modules and to setup the proxied connection from Apache to Gitblit GO or from Apache to your chosen servlet container. The following snippet is stored as `/etc/apache2/conf.d/gitblit`. |
|---|
| | | ---FIXED---
|
|---|
| | | # Turn off support for true Proxy behaviour as we are acting as |
|---|
| | | # a transparent proxy
|
|---|
| | | ProxyRequests Off
|
|---|
| | |
|
|---|
| | | # Turn off VIA header as we know where the requests are proxied
|
|---|
| | | ProxyVia Off
|
|---|
| | | |
|---|
| | | # Turn on Host header preservation so that the servlet container
|
|---|
| | | # can write links with the correct host and rewriting can be avoided.
|
|---|
| | | #
|
|---|
| | | # This is important for all git push/pull/clone operations.
|
|---|
| | | ProxyPreserveHost On
|
|---|
| | | |
|---|
| | | # Set the permissions for the proxy
|
|---|
| | | <Proxy>
|
|---|
| | | AddDefaultCharset off
|
|---|
| | | Order deny,allow
|
|---|
| | | Allow from all
|
|---|
| | | </Proxy>
|
|---|
| | | |
|---|
| | | # The proxy context path must match the Gitblit context path.
|
|---|
| | | # For Gitblit GO, see server.contextPath in gitblit.properties.
|
|---|
| | |
|
|---|
| | | #ProxyPass /gitblit http://localhost:8080/gitblit
|
|---|
| | | #ProxyPassreverse /gitblit http://localhost:8080/gitblit
|
|---|
| | |
|
|---|
| | | # If your httpd frontend is https but you are proxying http Gitblit WAR or GO
|
|---|
| | | #Header edit Location ^http://([^⁄]+)/gitblit/ https://$1/gitblit/
|
|---|
| | |
|
|---|
| | | # Additionally you will want to tell Gitblit the original scheme and port
|
|---|
| | | #RequestHeader set X-Forwarded-Proto https
|
|---|
| | | #RequestHeader set X-Forwarded-Port 443
|
|---|
| | |
|
|---|
| | | # If you are using subdomain proxying then you will want to tell Gitblit the appropriate
|
|---|
| | | # context path for your repository url.
|
|---|
| | | # If you are not using subdomain proxying, then ignore this setting.
|
|---|
| | | #RequestHeader set X-Forwarded-Context /
|
|---|
| | |
|
|---|
| | | #ProxyPass /gitblit ajp://localhost:8009/gitblit
|
|---|
| | | ---FIXED--- |
|---|
| | | **Please** make sure to: |
|---|
| | | 1. Review the security of these settings as appropriate for your deployment
|
|---|
| | | 2. Uncomment the *ProxyPass* setting for whichever connection you prefer (http/ajp)
|
|---|
| | | 3. Correctly set the ports and context paths both in the *ProxyPass* definition and your Gitblit installation |
|---|
| | | If you are using Gitblit GO you can easily configure the AJP connector by specifying a non-zero AJP port. |
|---|
| | | Please remember that on Linux/UNIX, ports < 1024 require root permissions to open.
|
|---|
| | | 4. Set *web.mountParameters=false* in `gitblit.properties` or `web.xml` this will use parameterized URLs. |
|---|
| | | Alternatively, you can respecify *web.forwardSlashCharacter*.
|
|---|
| | |
|
|---|
| | | ## Upgrading Gitblit
|
|---|
| | |
|
|---|
| | | Any important changes to the setting keys or default values will always be mentioned in the [release log](releases.html).
|
|---|
| | |
|
|---|
| | | Gitblit v0.8.0 introduced a new default user service implementation which serializes and deserializes user objects into `users.conf`. A `users.conf` file will be automatically created from an existing `users.properties` file on the first launch after an upgrade. To use the `users.conf` service, *realm.userService=users.conf* must be set. This revised user service allows for more sophisticated Gitblit user objects and will facilitate the development of more advanced features without adding the complexity of an embedded SQL database.
|
|---|
| | |
|
|---|
| | | `users.properties` and its user service implementation are deprecated as of v0.8.0.
|
|---|
| | |
|
|---|
| | | ### Upgrading Gitblit WAR (1.2.1+)
|
|---|
| | | 1. Make sure your `WEB-INF/web.xml` *baseFolder* context parameter is not `${contextFolder}/WEB-INF/data`!<br/>
|
|---|
| | | If it is, move your `WEB-INF/data` folder to a location writeable by your servlet container.
|
|---|
| | | 2. Deploy new WAR
|
|---|
| | | 3. Edit the new WAR's `WEB-INF/web.xml` file and set the *baseFolder* context parameter to your external baseFolder.
|
|---|
| | | 4. Review and optionally apply any new settings as indicated in the [release log](releases.html) to `${baseFolder}/gitblit.properties`. |
|---|
| | | |
|---|
| | | ### Upgrading Gitblit GO (1.2.1+)
|
|---|
| | | |
|---|
| | | 1. Unzip Gitblit GO to a new folder
|
|---|
| | | 2. Copy your `data` folder from your current Gitblit installation to the new folder and overwrite any conflicts
|
|---|
| | | 3. Review and optionally apply any new settings as indicated in the [release log](releases.html) to `data/gitblit.properties`.
|
|---|
| | |
|
|---|
| | | In *nix systems, there are other tricks you can play like symlinking the `data` folder or symlinking the GO folder.
|
|---|
| | | All platforms support the *--baseFolder* command-line argument.
|
|---|
| | |
|
|---|
| | | ### Upgrading Gitblit WAR (pre-1.2.1)
|
|---|
| | |
|
|---|
| | | 1. Create a `data` as outlined in step 1 of *Upgrading Gitblit GO (pre-1.2.1)*
|
|---|
| | | 2. Copy your existing web.xml to your data folder
|
|---|
| | | 3. Deploy new WAR
|
|---|
| | | 4. Copy the new WAR's `WEB-INF/data/gitblit.properties` file to your data folder
|
|---|
| | | 5. Manually apply any changes you made to your original web.xml file to the gitblit.properties file you copied to your data folder
|
|---|
| | | 6. Edit the new WAR's `WEB-INF/web.xml` file and set the *baseFolder* context parameter to your external baseFolder.
|
|---|
| | |
|
|---|
| | | ### Upgrading Gitblit GO (pre-1.2.1)
|
|---|
| | | 1. Create a `data` folder and copy the following files and folders to it:
|
|---|
| | | - **users.conf*
|
|---|
| | | - **projects.conf** *(if you have one)*
|
|---|
| | | - **gitblit.properties**
|
|---|
| | | - **serverKeystore.jks**
|
|---|
| | | - **serverTrustStore.jks**
|
|---|
| | | - *certs** folder
|
|---|
| | | - **git** folder
|
|---|
| | | - **groovy** folder
|
|---|
| | | - **proposals** folder
|
|---|
| | | - and any other custom files (robots.txt, welcome/login markdown files, etc)
|
|---|
| | | - then edit your `gitblit.properties` file and adjust the following settings:
|
|---|
| | | - *git.repositoriesFolder* = ${baseFolder}/git
|
|---|
| | | - *groovy.scriptsFolder* = ${baseFolder}/groovy
|
|---|
| | | - *groovy.grapeFolder* = ${baseFolder}/groovy/grape
|
|---|
| | | - *web.projectsFile* = ${baseFolder}/projects.conf
|
|---|
| | | - *realm.userService* = ${baseFolder}/users.conf
|
|---|
| | | - *web.robots.txt* = ${baseFolder}/robots.txt
|
|---|
| | | - *federation.proposalsFolder* = ${baseFolder}/proposals
|
|---|
| | | - *realm.ldap.backingUserService* = ${baseFolder}/users.conf
|
|---|
| | | - *realm.redmine.backingUserService* = ${baseFolder}/users.conf
|
|---|
| | | - *server.tempFolder* = ${baseFolder}/temp
|
|---|
| | |
|
|---|
| | | 2. Unzip Gitblit GO to a new folder
|
|---|
| | | 3. Copy your `data` folder and overwrite the folder of the same name in the just-unzipped version
|
|---|
| | | 4. Review and optionally apply any new settings as indicated in the [release log](releases.html) to `data/gitblit.properties`.
|
|---|
| | |
|
|---|
| | | **NOTE:** You may need to adjust your service definitions to include the `--baseFolder data` argument.
|
|---|
| | |
|
|---|
| | | #### Upgrading Windows Service
|
|---|
| | | You may need to delete your old service definition and install a new one depending on what has changed in the release.
|
|---|
| | |
|
|---|
| | | ## Gitblit Configuration
|
|---|
| | |
|
|---|
| | | ### Administering Repositories
|
|---|
| | |
|---|
| | |
|
|---|
| | | **What about merges?**
|
|---|
| | |
|
|---|
| | | You can not use fast-forward merges on your client when using committer verification. You must specify *--no-ff* to ensure that a merge commit is created with your identity as the committer. Only the first parent chain is traversed when verifying commits.
|
|---|
| | | You can not use fast-forward merges on your client when using committer verification. You must specify *--no-ff* to ensure that a merge commit is created with your identity as the committer. Only the first/left parent chain is traversed when verifying commits.
|
|---|
| | |
|
|---|
| | | #### Push Log
|
|---|
| | | #### Reflog
|
|---|
| | |
|
|---|
| | | Gitblit v1.2.1 introduces an incomplete push mechanism. All pushes are logged since 1.2.1, but the log has not yet been exposed through the web ui. This will be a feature of an upcoming release.
|
|---|
| | | Gitblit v1.2.1 introduced an incomplete reflog mechanism which was completed in 1.3.0. All pushes to Gitblit are automatically logged on an orphan branch, refs/gitblit/reflog. If this ref exists, the reflog page link will be displayed on the repository pages.
|
|---|
| | |
|
|---|
| | | This reflog is similar to, but not the same as, the normal Git reflog. The Gitblit reflog links Gitblit accounts to ref changes and because it is stored on an orphan branch, the reflog is portable by the federation mechanism or by a normal <code>git clone --mirror</code> command.
|
|---|
| | |
|
|---|
| | | ### Teams
|
|---|
| | |
|
|---|
| | | Since v0.8.0, Gitblit supports *teams* for the original `users.properties` user service and the current default user service `users.conf`. Teams have assigned users and assigned repositories. A user can be a member of multiple teams and a repository may belong to multiple teams. This allows the administrator to quickly add a user to a team without having to keep track of all the appropriate repositories. |
|---|
| | | Teams have assigned users and assigned repositories. A user can be a member of multiple teams and a repository may belong to multiple teams. This allows the administrator to quickly add a user to a team without having to keep track of all the appropriate repositories. |
|---|
| | |
|
|---|
| | | ### Administering Users (users.conf, Gitblit v0.8.0+)
|
|---|
| | | All users are stored in the `users.conf` file or in the file you specified in `gitblit.properties`. Your file extension must be *.conf* in order to use this user service.
|
|---|
| | | ### Administering Users
|
|---|
| | | All users and permissions are stored in the `users.conf` file. Your file extension must be *.conf* in order to use this user service.
|
|---|
| | |
|
|---|
| | | The `users.conf` file uses a Git-style configuration format:
|
|---|
| | |
|
|---|
| | |
|---|
| | | mailingList = list@ateam.org
|
|---|
| | | postReceiveScript = sendmail
|
|---|
| | |
|
|---|
| | | The `users.conf` file allows flexibility for adding new fields to a UserModel object that the original `users.properties` file does not afford without imposing the complexity of relying on an embedded SQL database. |
|---|
| | |
|
|---|
| | | ### Administering Users (users.properties, Gitblit v0.5.0 - v0.7.0)
|
|---|
| | | All users are stored in the `users.properties` file or in the file you specified in `gitblit.properties`. Your file extension must be *.properties* in order to use this user service.
|
|---|
| | |
|
|---|
| | | The format of `users.properties` loosely follows Jetty's convention for HashRealms:
|
|---|
| | |
|
|---|
| | | username=password,role1,role2,role3...
|
|---|
| | | @teamname=&mailinglist,!username1,!username2,!username3,repository1,repository2,repository3...
|
|---|
| | | The `users.conf` file allows flexibility for adding new fields to a UserModel object without imposing the complexity of relying on an embedded SQL database. |
|---|
| | |
|
|---|
| | | ### Usernames
|
|---|
| | | Usernames must be unique and are case-insensitive.
|
|---|
| | |
|---|
| | | ### User Roles
|
|---|
| | | There are four actual *roles* in Gitblit:
|
|---|
| | |
|
|---|
| | | - *#admin*, which grants administrative powers to that user
|
|---|
| | | - *#admin*, which grants administrative powers to that user for all repositories, users, and teams
|
|---|
| | | - *#notfederated*, which prevents an account from being pulled by another Gitblit instance
|
|---|
| | | - *#create*, which allows the user the power to create personal repositories
|
|---|
| | | - *#fork*, which allows the user to create a personal fork of an existing Gitblit-hosted repository
|
|---|
| | |
|
|---|
| | | Administrators automatically have access to all repositories. All other *roles* are repository permissions. If a repository is access-restricted, the user must have the repository's name within his/her roles to bypass the access restriction. This is how users are granted access to a restricted repository.
|
|---|
| | |
|
|---|
| | | **NOTE:**
|
|---|
| | | The following roles are equivalent:
|
|---|
| | | The following repository permissions are equivalent:
|
|---|
| | |
|
|---|
| | | - myrepo.git
|
|---|
| | | - RW+:myrepo.git
|
|---|
| | |
|---|
| | | In other words, if you fork *RepoA.git* to *~me/RepoA.git* and then set the access restriction of *~me/RepoA.git* to *Authenticated View, Clone, & Push* your fork will still be listed in the fork network for *RepoA.git*.
|
|---|
| | |
|
|---|
| | | If you really must have an invisible fork, the clone it locally, create a new personal repository for your invisible fork, and push it back to that personal repository.
|
|---|
| | |
|
|---|
| | | ## Alternative Authentication and Authorization
|
|---|
| | |
|
|---|
| | | ### LDAP Authentication
|
|---|
| | | *SINCE 1.0.0*
|
|---|
| | |
|
|---|
| | | LDAP can be used to authenticate Users and optionally control Team memberships. When properly configured, Gitblit will delegate authentication to your LDAP server and will cache some user information in the usual users file (.conf or .properties).
|
|---|
| | |
|
|---|
| | | When using the LDAP User Service, new user accounts can not be manually created from Gitblit. Gitblit user accounts are automatically created for new users on their first succesful authentication through Gitblit against the LDAP server. It is also important to note that the LDAP User Service does not retrieve or store user passwords nor does it implement any LDAP-write functionality.
|
|---|
| | |
|
|---|
| | | To use the *LdapUserService* set *realm.userService=com.gitblit.LdapUserService* in your `gitblit.properties` file or your `web.xml` file and then configure the *realm.ldap* settings appropriately for your LDAP environment.
|
|---|
| | |
|
|---|
| | | #### Example LDAP Layout
|
|---|
| | | 
|
|---|
| | |
|
|---|
| | | Please see [ldapUserServiceSampleData.ldif](https://github.com/gitblit/gitblit/blob/master/tests/com/gitblit/tests/resources/ldapUserServiceSampleData.ldif) to see the data in LDAP that reflects the above picture.
|
|---|
| | |
|
|---|
| | | #### Gitblit Settings for Example LDAP Layout
|
|---|
| | | The following are the settings required to configure Gitblit to authenticate against the example LDAP server with LDAP-controlled team memberships.
|
|---|
| | |
|
|---|
| | | <table class="table">
|
|---|
| | | <thead>
|
|---|
| | | <tr><th>parameter</th><th>value</th><th>description</th></tr>
|
|---|
| | | </thead>
|
|---|
| | | <tbody>
|
|---|
| | | <tr>
|
|---|
| | | <th>realm.ldap.server</th><td>ldap://localhost:389</td>
|
|---|
| | | <td>Tells Gitblit to connect to the LDAP server on localhost port 389. The URL Must be of form ldap(s)://<server>:<port> with port being optional (389 for ldap, 636 for ldaps).</td>
|
|---|
| | | </tr>
|
|---|
| | | <tr>
|
|---|
| | | <th>realm.ldap.username</th><td>cn=Directory Manager</td>
|
|---|
| | | <td>The credentials that will log into the LDAP server</td>
|
|---|
| | | </tr>
|
|---|
| | | <tr>
|
|---|
| | | <th>realm.ldap.password</th><td>password</td>
|
|---|
| | | <td>The credentials that will log into the LDAP server</td>
|
|---|
| | | </tr>
|
|---|
| | | <tr>
|
|---|
| | | <th>realm.ldap.backingUserService</th><td>users.conf</td>
|
|---|
| | | <td>Where to store all information that is used by Gitblit. All information will be synced here upon user login.</td>
|
|---|
| | | </tr>
|
|---|
| | | <tr>
|
|---|
| | | <th>realm.ldap.maintainTeams</th><td>true</td>
|
|---|
| | | <td>Are team memberships maintained in LDAP (<em>true</em>) or manually in Gitblit (<em>false</em>).</td>
|
|---|
| | | </tr>
|
|---|
| | | <tr>
|
|---|
| | | <th>realm.ldap.accountBase</th><td>OU=Users,OU=UserControl,OU=MyOrganization,DC=MyDomain</td>
|
|---|
| | | <td>What is the root node for all users in this LDAP system. Subtree searches will start from this node.</td>
|
|---|
| | | </tr>
|
|---|
| | | <tr>
|
|---|
| | | <th>realm.ldap.accountPattern</th><td>(&(objectClass=person)(sAMAccountName=${username}))</td><td>The LDAP search filter that will match a particular user in LDAP. ${username} will be replaced with whatever the user enters as their username in the Gitblit login panel.</td>
|
|---|
| | | </tr>
|
|---|
| | | <tr>
|
|---|
| | | <th>realm.ldap.groupBase</th><td>OU=Groups,OU=UserControl,OU=MyOrganization,DC=MyDomain</td>
|
|---|
| | | <td>What is the root node for all teams in this LDAP system. Subtree searches will start from this node.</td>
|
|---|
| | | </tr>
|
|---|
| | | <tr>
|
|---|
| | | <th>realm.ldap.groupMemberPattern</th><td>(&(objectClass=group)(member=${dn}))</td><td>The LDAP search filter that will match all teams for the authenticating user. ${username} will be replaced with whatever the user enters as their username in the Gitblit login panel. Anything else in ${} will be replaced by Attributes from the User node.</td>
|
|---|
| | | </tr>
|
|---|
| | | <tr>
|
|---|
| | | <th>realm.ldap.admins</th><td>@Git_Admins</td><td>A space-delimited list of usernames and/or teams that indicate admin status in Gitblit. Teams are referenced with a leading <em>@</em> character.</td>
|
|---|
| | | </tr>
|
|---|
| | | </tbody>
|
|---|
| | | </table>
|
|---|
| | |
|
|---|
| | | #### LDAP In-Memory Server
|
|---|
| | |
|
|---|
| | | You can start Gitblit GO with an in-memory LDAP server by specifying the *--ldapLdifFile* command-line argument. The LDAP server will listen on localhost of the port specified in *realm.ldap.url* of `gitblit.properties`. Additionally, a root user record is automatically created for *realm.ldap.username* and *realm.ldap.password*. Please note that the ldaps:// protocol is not supported for the in-memory server.
|
|---|
| | |
|
|---|
| | | ### Custom Authentication
|
|---|
| | | This is the simplest choice where you implement custom authentication and delegate all other standard user and team operations to one of Gitblit's user service implementations. This choice insulates your customization from changes in User and Team model classes and additional API that may be added to IUserService.
|
|---|
| | |
|
|---|
| | | Please subclass [com.gitblit.GitblitUserService](https://github.com/gitblit/gitblit/blob/master/src/com/gitblit/GitblitUserService.java) and override the *setup()* and *authenticate()* methods. |
|---|
| | | Make sure to set the *serviceImpl* field in your *setup()* method.
|
|---|
| | |
|
|---|
| | | You may use your subclass by specifying its fully qualified classname in the *realm.userService* setting.
|
|---|
| | |
|
|---|
| | | Your subclass must be on Gitblit's classpath and must have a public default constructor. |
|---|
| | |
|
|---|
| | | ### Custom Everything
|
|---|
| | | Instead of maintaining a `users.conf` or `users.properties` file, you may want to integrate Gitblit into an existing environment.
|
|---|
| | |
|
|---|
| | | You may use your own custom *com.gitblit.IUserService* implementation by specifying its fully qualified classname in the *realm.userService* setting.
|
|---|
| | |
|
|---|
| | | Your user service class must be on Gitblit's classpath and must have a public default constructor. |
|---|
| | | Please see the following interface definition [com.gitblit.IUserService](https://github.com/gitblit/gitblit/blob/master/src/com/gitblit/IUserService.java).
|
|---|
| | |
|
|---|
| | | ## Groovy Hook Scripts
|
|---|
| | |
|
|---|
| | | *SINCE 0.8.0*
|
|---|
| | |
|
|---|
| | | Gitblit uses Groovy for its push hook mechanism. This mechanism only executes when pushing to Gitblit, not when pushing to some other Git tooling in your stack.
|
|---|
| | |
|
|---|
| | | The Groovy hook mechanism allows for dynamic extension of Gitblit to execute custom tasks on receiving and processing push events. The scripts run within the context of your Gitblit instance and therefore have access to Gitblit's internals at runtime.
|
|---|
| | |
|
|---|
| | | ### Rules, Requirements, & Behaviors
|
|---|
| | | 1. Your Groovy scripts must be stored in the *groovy.scriptsFolder* as specified in `gitblit.properties` or `web.xml`.
|
|---|
| | | 2. All script files must have the *.groovy* extension. Because of this you may omit the extension when specifying the script.
|
|---|
| | | 3. Script filenames must not have spaces!
|
|---|
| | | 4. Scripts must be explicitly specified to be executed, no scripts are *automatically* executed by name or extension.
|
|---|
| | | 5. A script can be specified to run on *all repositories* by adding the script file name to *groovy.preReceiveScripts* or *groovy.postReceiveScripts* in `gitblit.properties` or `web.xml`.
|
|---|
| | | 6. Scripts can be specified for a team.
|
|---|
| | | 7. Scripts may also be specified per-repository in the repository's settings.
|
|---|
| | | 8. Globally-specified scripts and team-specified scripts are excluded from the list of available scripts in a repository's settings |
|---|
| | | 9. Globally-specified scripts are executed first, in their listed order; followed by team-specified scripts in their listed order by alphabetical team order; followed by per-repository scripts, in their listed order.
|
|---|
| | | 10. A script may only be defined once in a pre-receive chain and once in a post-receive chain. |
|---|
| | | You may execute the same script on pre-receive and post-receive, just not multiple times within a pre-receive or post-receive event.
|
|---|
| | | 11. Gitblit does not differentiate between what can be a pre-receive script and what can be a post-receive script.
|
|---|
| | | 12. If a script *returns false* then the hook chain is aborted and none of the subsequent scripts will execute.
|
|---|
| | |
|
|---|
| | | Some sample scripts are included in the GO and WAR distributions to show you how you can tap into Gitblit with the provided bound variables. Additional implementation details may be specified in the header comment of these examples.
|
|---|
| | |
|
|---|
| | | Hook contributions and improvements are welcome.
|
|---|
| | |
|
|---|
| | | ### Grapes
|
|---|
| | |
|
|---|
| | | *SINCE 1.0.0*
|
|---|
| | |
|
|---|
| | | [Grape](http://groovy.codehaus.org/Grape) lets you quickly add maven repository dependencies to your Groovy hook script. |
|---|
| | |
|
|---|
| | | <blockquote>Grape (The Groovy Adaptable Packaging Engine or Groovy Advanced Packaging Engine) is the infrastructure enabling the grab() calls in Groovy, a set of classes leveraging <a href="http://ant.apache.org/ivy">Ivy</a> to allow for a repository driven module system for Groovy. This allows a developer to write a script with an essentially arbitrary library requirement, and ship just the script. Grape will, at runtime, download as needed and link the named libraries and all dependencies forming a transitive closure when the script is run from existing repositories such as Ibiblio, Codehaus, and java.net.</blockquote>
|
|---|
| | |
|
|---|
| | | ---JAVA---
|
|---|
| | | // create and use a primitive array
|
|---|
| | | import org.apache.commons.collections.primitives.ArrayIntList
|
|---|
| | |
|
|---|
| | | @Grab(group='commons-primitives', module='commons-primitives', version='1.0')
|
|---|
| | | def createEmptyInts() { new ArrayIntList() }
|
|---|
| | |
|
|---|
| | | def ints = createEmptyInts()
|
|---|
| | | ints.add(0, 42)
|
|---|
| | | assert ints.size() == 1
|
|---|
| | | assert ints.get(0) == 42
|
|---|
| | | ---JAVA---
|
|---|
| | |
|
|---|
| | | ### Custom Fields
|
|---|
| | |
|
|---|
| | | *SINCE 1.0.0*
|
|---|
| | |
|
|---|
| | | Gitblit allows custom repository string fields to be defined in `gitblit.properties` or `web.xml`. Entry textfields are automatically created for these fields in the Edit Repository page of Gitblit and the Edit Repository dialog of the Gitblit Manager. These fields are accessible from your Groovy hook scripts as
|
|---|
| | |
|
|---|
| | | repository.customFields.myField
|
|---|
| | |
|
|---|
| | | This feature allows you to customize the behavior of your hook scripts without hard-coding values in the hook scripts themselves.
|
|---|
| | |
|
|---|
| | | ### Pre-Receive
|
|---|
| | |
|
|---|
| | | Pre-Receive scripts execute after the pushed objects have all been written to the Git repository but before the refs have been updated to point to these new objects.
|
|---|
| | |
|
|---|
| | | This is the appropriate point to block a push and is how many Git tools implement branch-write permissions.
|
|---|
| | |
|
|---|
| | | ### Post-Receive
|
|---|
| | |
|
|---|
| | | Post-Receive scripts execute after all refs have been updated.
|
|---|
| | |
|
|---|
| | | This is the appropriate point to trigger continuous integration builds or send email notifications, etc.
|
|---|
| | |
|
|---|
| | | ## Push Email Notifications
|
|---|
| | |
|
|---|
| | | Gitblit implements email notifications in *sendmail.groovy* which uses the Groovy Hook Script mechanism. This allows for dynamic customization of the notification process at the installation site and serves as an example push script.
|
|---|
| | |
|
|---|
| | | ### Enabling Push Notifications
|
|---|
| | |
|
|---|
| | | In order to send email notifications on a push to Gitblit, this script must be specified somewhere in the *post-receive* script chain. |
|---|
| | | You may specify *sendmail* in one of three places:
|
|---|
| | |
|
|---|
| | | 1. *groovy.postReceiveScripts* in `gitblit.properties` or `web.xml`, globally applied to all repositories
|
|---|
| | | 2. post-receive scripts of a Team definition
|
|---|
| | | 3. post-receive scripts of a Repository definition
|
|---|
| | |
|
|---|
| | | ### Destination Addresses
|
|---|
| | |
|
|---|
| | | Gitblit does not currently support individual subscriptions to repositories; i.e. a *user* can not subscribe or unsubscribe from push notifications.
|
|---|
| | |
|
|---|
| | | However, Repository Managers and Administrators can specify subscribed email addresses in one of three places:
|
|---|
| | |
|
|---|
| | | 1. *mail.mailingLists* in `gitblit.properties` or `web.xml`, globally applied to all push-notified repositories
|
|---|
| | | 2. mailing lists in a Team definition, applied to all repositories that are part of the team definition
|
|---|
| | | 3. mailing lists in a Repository definition
|
|---|
| | |
|
|---|
| | | All three sources are checked and merged into a unique list of destination addresses for push notifications.
|
|---|
| | |
|
|---|
| | | **NOTE:** |
|---|
| | | Care should be taken when devising your notification scheme as it relates to any VIEW restricted repositories you might have. Setting a global mailing list and activating push notifications for a VIEW restricted repository may send unwanted emails.
|
|---|
| | |
|
|---|
| | | ## Lucene Search Integration
|
|---|
| | |
|
|---|
| | | *SINCE 0.9.0*
|
|---|
| | |
|
|---|
| | | Repositories may optionally be indexed using the Lucene search engine. The Lucene search offers several advantages over commit-traversal search:
|
|---|
| | |
|
|---|
| | | 1. very fast commit and blob searches
|
|---|
| | | 2. multi-term searches
|
|---|
| | | 3. term-highlighted and syntax-highlighted fragment matches
|
|---|
| | | 4. multi-repository searches
|
|---|
| | |
|
|---|
| | | ### How do I use it?
|
|---|
| | |
|
|---|
| | | First you must ensure that *web.allowLuceneIndexing* is set *true* in `gitblit.properties` or `web.xml`. Then you must understand that Lucene indexing is an opt-in feature which means that no repositories are automatically indexed. |
|---|
| | | Like anything else, this design has pros and cons.
|
|---|
| | |
|
|---|
| | | #### Pros
|
|---|
| | | 1. no wasted cycles indexing repositories you will never search
|
|---|
| | | 2. you specify exactly what branches are indexed; experimental/dead/personal branches can be ignored
|
|---|
| | |
|
|---|
| | | #### Cons
|
|---|
| | | 1. you specify exactly what branches are indexed
|
|---|
| | |
|
|---|
| | | #### I have 300 repositories and you want me to specify indexed branches on each one??
|
|---|
| | |
|
|---|
| | | Yeah, I agree that is inconvenient.
|
|---|
| | |
|
|---|
| | | If you are using Gitblit GO there is a utility script `add-indexed-branch.cmd` which allows you to specify an indexed branch for many repositories in one step.
|
|---|
| | |
|
|---|
| | | If you are using Gitblit WAR then, at present, you are out of luck unless you write your own script to traverse your repositories and use native Git to manipulate each repository config.
|
|---|
| | |
|
|---|
| | | git config --add gitblit.indexBranch "default"
|
|---|
| | | git config --add gitblit.indexBranch "refs/heads/master"
|
|---|
| | |
|
|---|
| | | #### Indexing Branches
|
|---|
| | | You may specify which branches should be indexed per-repository in the *Edit Repository* page. New/empty repositories may only specify the *default* branch which will resolve to whatever commit HEAD points to or the most recently updated branch if HEAD is unresolvable.
|
|---|
| | |
|
|---|
| | | Indexes are built and incrementally updated on a 2 minute cycle so you may have to wait a few minutes before your index is built or before your latest pushes get indexed.
|
|---|
| | |
|
|---|
| | | **NOTE:** |
|---|
| | | After specifying branches, only the content from those branches can be searched via Gitblit. Gitblit will automatically redirect any queries entered on a repository's search box to the Lucene search page. Repositories that do not specify any indexed branches will use the traditional commit-traversal search.
|
|---|
| | |
|
|---|
| | | #### Adequate Heap
|
|---|
| | |
|
|---|
| | | The initial indexing of an existing repository can potentially exhaust the memory allocated to your Java instance and may throw OutOfMemory exceptions. Be sure to provide your Gitblit server adequate heap space to index your repositories. The heap is set using the *-Xmx* JVM parameter in your Gitblit launch command (e.g. -Xmx1024M).
|
|---|
| | |
|
|---|
| | | #### Why does Gitblit check every 2 mins for repository/branch changes?
|
|---|
| | |
|
|---|
| | | Gitblit has to balance its design as a complete, integrated Git server and its utility as a repository viewer in an existing Git setup.
|
|---|
| | |
|
|---|
| | | Gitblit could build indexes immediately on *edit repository* or on *receiving pushes*, but that design would not work if someone is pushing via ssh://, git://, or file:// (i.e. not pushing to Gitblit http(s)://). For this reason Gitblit has a polling mechanism to check for ref changes every 2 mins. This design works well for all use cases, aside from adding a little lag in updating the index.
|
|---|
| | |
|
|---|
| | | ## Client Setup and Configuration
|
|---|
| | | ### Https with Self-Signed Certificates
|
|---|
| | | You must tell Git/JGit not to verify the self-signed certificate in order to perform any remote Git operations.
|
|---|
| | |
|
|---|
| | | **NOTE:** |
|---|
| | | The default self-signed certificate generated by Gitlbit GO is bound to *localhost*. |
|---|
| | | If you are using Eclipse/EGit/JGit clients, you will have to generate your own certificate that specifies the exact hostname used in your clone/push url. |
|---|
| | | You must do this because Eclipse/EGit/JGit (< 3.0) always verifies certificate hostnames, regardless of the *http.sslVerify=false* client-side setting. |
|---|
| | | |
|---|
| | | - **Eclipse/EGit/JGit**
|
|---|
| | | 1. Window->Preferences->Team->Git->Configuration
|
|---|
| | | 2. Click the *New Entry* button
|
|---|
| | | 3. <pre>Key = <em>http.sslVerify</em>
|
|---|
| | | Value = <em>false</em></pre>
|
|---|
| | | - **Command-line Git** ([Git-Config Manual Page](http://www.kernel.org/pub/software/scm/git/docs/git-config.html)) |
|---|
| | | <pre>git config --global --bool --add http.sslVerify false</pre>
|
|---|
| | |
|
|---|
| | | ### Http Post Buffer Size
|
|---|
| | | You may find the default post buffer of your git client is too small to push large deltas to Gitblit. Sometimes this can be observed on your client as *hanging* during a push. Other times it can be observed by git erroring out with a message like: error: RPC failed; result=52, HTTP code = 0.
|
|---|
| | |
|
|---|
| | | This can be adjusted on your client by changing the default post buffer size:
|
|---|
| | | <pre>git config --global http.postBuffer 524288000</pre>
|
|---|
| | |
|
|---|
| | | ### Disabling SNI
|
|---|
| | |
|
|---|
| | | You may run into SNI alerts (Server Name Indication). These will manifest as failures to clone or push to your Gitblit instance.
|
|---|
| | |
|
|---|
| | | #### Java-based Clients
|
|---|
| | |
|
|---|
| | | When using Java 7-based clients, SNI is enabled by default. You can disable SNI by specifying the JVM system parameter `-Djsse.enableSNIExtension=false` when your Java-based client launches.
|
|---|
| | |
|
|---|
| | | For Eclipse, you can append `-Djsse.enableSNIExtension=false` to your *eclipse.ini* file.
|
|---|
| | |
|
|---|
| | | #### Native Clients
|
|---|
| | |
|
|---|
| | | Native clients may display an error when attempting to clone or push that looks like this:
|
|---|
| | | ---FIXED---
|
|---|
| | | C:\projects\git\gitblit>git push rhcloud master
|
|---|
| | | error: error:14077458:SSL routines:SSL23_GET_SERVER_HELLO:reason(1112) while accessing https://demo-gitblit.rhcloud.com/git/gitblit.git/info/refs?service=git-receive-pack
|
|---|
| | | fatal: HTTP request failed
|
|---|
| | | ---FIXED---
|
|---|
| | |
|
|---|
| | | ### Cloning an Access Restricted Repository |
|---|
| | | - **Eclipse/EGit/JGit** |
|---|
| | | Nothing special to configure, EGit figures out everything.
|
|---|
| | | <pre>https://yourserver/git/your/repository</pre>
|
|---|
| | | - **Command-line Git** |
|---|
| | | My testing indicates that your username must be embedded in the url. YMMV. |
|---|
| | | <pre>https://username@yourserver/git/your/repository</pre>
|
|---|
| | |
|
|---|
