| | |
|---|
| | | Open `web.xml` in your favorite text editor and make sure to review and set:
|
|---|
| | | - <context-parameter> *git.repositoryFolder* (set the full path to your repositories folder)
|
|---|
| | | - <context-parameter> *groovy.scriptsFolder* (set the full path to your Groovy hook scripts folder)
|
|---|
| | | - <context-parameter> *groovy.grapeFolder* (set the full path to your Groovy Grape artifact cache)
|
|---|
| | | - <context-parameter> *web.projectsFile* (set the full path to your projects metadata file)
|
|---|
| | | - <context-parameter> *realm.userService* (set the full path to `users.conf`)
|
|---|
| | | - <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)
|
|---|
| | | 5. You may have to restart your servlet container.
|
|---|
| | | 6. Open your browser to <http://localhost/gitblit> or whatever the url should be.
|
|---|
| | | 7. Enter the default administrator credentials: **admin / admin** and click the *Login* button
|
|---|
| | |
|---|
| | | Open `gitblit.properties` in your favorite text editor and make sure to review and set:
|
|---|
| | | - *git.repositoryFolder* (path may be relative or absolute)
|
|---|
| | | - *groovy.scriptsFolder* (path may be relative or absolute)
|
|---|
| | | - *groovy.grapeFolder* (path may be relative or absolute)
|
|---|
| | | - *server.tempFolder* (path may be relative or absolute)
|
|---|
| | | - *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!
|
|---|
| | | 3. Execute `gitblit.cmd` or `java -jar gitblit.jar` from a command-line
|
|---|
| | | 4. Wait a minute or two while all dependencies are downloaded and your self-signed *localhost* certificate is generated. |
|---|
| | | Please see the section titled **Creating your own Self-Signed Certificate** to generate a certificate for *your hostname*.
|
|---|
| | | - *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 -jar authority.jar` 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` 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!!
|
|---|
| | |
|
|---|
| | | ### Creating your own Self-Signed Certificate
|
|---|
| | | Gitblit GO automatically generates an ssl certificate for you that is bound to *localhost*.
|
|---|
| | | ### 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 (<= 1.1.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.
|
|---|
| | | Remote Eclipse/EGit/JGit clients (<= 2.1.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 your own certificate.
|
|---|
| | | 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. Review the contents of `makekeystore.cmd` or `makekeystore_jdk.cmd`
|
|---|
| | | 2. Set *your hostname* into the *HOSTNAME* variable.
|
|---|
| | | 3. Execute the script.<br/>This will generate a new certificate and keystore for *your hostname* protected by *server.storePassword*.
|
|---|
| | | 1. `authority.cmd` or `java -jar authority.jar`
|
|---|
| | | 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
|
|---|
| | |
|
|---|
| | | **NOTE:** |
|---|
| | | If you use `makekeystore_jdk.cmd`, the certificate password AND the keystore password must match and must be set as *server.storePassword* or specified with the *storePassword* command-line parameter!
|
|---|
| | | 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:
|
|---|
| | |
|
|---|
| | | Additionally, if you want to change the value of *server.storePassword* (recommended) you will have to generate a new certificate afterwards.
|
|---|
| | | 1. serverKeyStore.jks
|
|---|
| | | 2. serverTrustStore.jks
|
|---|
| | | 3. certs/caKeyStore.jks
|
|---|
| | | 4. certs/ca.crt
|
|---|
| | | 5. 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 `certs\instructions.tmpl` and can be modified to suit your needs.
|
|---|
| | |
|
|---|
| | | 1. `authority.cmd` or `java -jar authority.jar`
|
|---|
| | | 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.
|
|---|
| | |
|---|
| | | --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
|
|---|
| | |
|---|
| | |
|
|---|
| | | # 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
|
|---|
| | | %ENDCODE%
|
|---|
| | |
|---|
| | | federationSets =
|
|---|
| | |
|
|---|
| | | #### Repository Names
|
|---|
| | | Repository names must be unique and are CASE-SENSITIVE ON CASE-SENSITIVE FILESYSTEMS. The name must be composed of letters, digits, or `/ _ - .`<br/>
|
|---|
| | | Repository names must be unique and are CASE-SENSITIVE ON CASE-SENSITIVE FILESYSTEMS. The name must be composed of letters, digits, or `/ _ - . ~`<br/>
|
|---|
| | | Whitespace is illegal.
|
|---|
| | |
|
|---|
| | | Repositories can be grouped within subfolders. e.g. *libraries/mycoollib.git* and *libraries/myotherlib.git*
|
|---|
| | |
|---|
| | |
|
|---|
| | | #### Repository Owner
|
|---|
| | | The *Repository Owner* has the special permission of being able to edit a repository through the web UI. The Repository Owner is not permitted to rename the repository, delete the repository, or reassign ownership to another user.
|
|---|
| | |
|
|---|
| | | ### Access Restrictions and Access Permissions
|
|---|
| | | 
|
|---|
| | |
|
|---|
| | | #### Discrete Permissions (Gitblit v1.2.0+)
|
|---|
| | |
|
|---|
| | | Since v1.2.0, Gitblit supports more discrete permissions. While Gitblit does not offer a built-in solution for branch-based permissions like Gitolite, it does allow for the following repository access permissions:
|
|---|
| | |
|
|---|
| | | - **V** (view in web ui, RSS feeds, download zip)
|
|---|
| | | - **R** (clone)
|
|---|
| | | - **RW** (clone and push)
|
|---|
| | | - **RWC** (clone and push with ref creation)
|
|---|
| | | - **RWD** (clone and push with ref creation, deletion)
|
|---|
| | | - **RW+** (clone and push with ref creation, deletion, rewind)
|
|---|
| | |
|
|---|
| | | These permission codes are combined with the repository path to create a user permission:
|
|---|
| | |
|
|---|
| | | RW:mygroup/myrepo.git
|
|---|
| | |
|
|---|
| | | #### Discrete Permissions with Regex Matching (Gitblit v1.2.0+)
|
|---|
| | |
|
|---|
| | | Gitblit also supports *case-insensitive* regex matching for repository permissions. The following permission grants push privileges to all repositories in the *mygroup* folder.
|
|---|
| | |
|
|---|
| | | RW:mygroup/.*
|
|---|
| | |
|
|---|
| | | ##### Exclusions
|
|---|
| | |
|
|---|
| | | When using regex matching it may also be useful to exclude specific repositories or to exclude regex repository matches. You may specify the **X** permission for exclusion. The following example grants clone permission to all repositories except the repositories in mygroup. The user/team will have no access whatsoever to these repositories.
|
|---|
| | |
|
|---|
| | | X:mygroup/.*
|
|---|
| | | R:.*
|
|---|
| | |
|
|---|
| | | ##### Order is Important
|
|---|
| | |
|
|---|
| | | The preceding example should suggest that order of permissions is important with regex matching. Here are the rules for determining the permission that is applied to a repository request:
|
|---|
| | |
|
|---|
| | | 1. If the user is an admin or repository owner, then RW+
|
|---|
| | | 2. Else if user has an explicit permission, use that
|
|---|
| | | 3. Else check for the first regex match in user permissions
|
|---|
| | | 4. Else check for the HIGHEST permission from team memberships
|
|---|
| | | 1. If the team is an admin team, then RW+
|
|---|
| | | 2. Else if a team has an explicit permission, use that
|
|---|
| | | 3. Else check for the first regex match in team permissions
|
|---|
| | |
|
|---|
| | | #### No-So-Discrete Permissions (Gitblit <= v1.1.0)
|
|---|
| | |
|
|---|
| | | Prior to v1.2.0, Gitblit has two main access permission groupings: |
|---|
| | |
|
|---|
| | | 1. what you are permitted to do as an anonymous user
|
|---|
| | | 2. **RW+** for any permitted user
|
|---|
| | |
|
|---|
| | | #### Committer Verification
|
|---|
| | |
|
|---|
| | | You may optionally enable committer verification which requires that each commit be committed by the authenticated user pushing the commits. i.e. If Bob is pushing the commits, Bob **must** be the committer of those commits.
|
|---|
| | |
|
|---|
| | | **How is this enforced?**
|
|---|
| | |
|
|---|
| | | Bob must set his *user.name* and *user.email* values for the repository to match his Gitblit user account **BEFORE** committing to his repository.
|
|---|
| | | <pre>
|
|---|
| | | [user "bob"]
|
|---|
| | | displayName = Bob Jones
|
|---|
| | | emailAddress = bob@somewhere.com
|
|---|
| | | </pre>
|
|---|
| | | <pre>
|
|---|
| | | git config user.name "Bob Jones"
|
|---|
| | | git config user.email bob@somewhere.com |
|---|
| | | </pre>
|
|---|
| | | or
|
|---|
| | |
|
|---|
| | | git config user.name bob
|
|---|
| | | git config user.email bob@somewhere.com |
|---|
| | |
|
|---|
| | | If the Gitblit account does not specify an email address, then the committer email address is ignored. However, if the account does specify an address it must match the committer's email address. Display name or username can be used as the committer name.
|
|---|
| | |
|
|---|
| | | All checks are case-insensitive.
|
|---|
| | |
|
|---|
| | | **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.
|
|---|
| | |
|
|---|
| | | ### Teams
|
|---|
| | |
|
|---|
| | |
|---|
| | | password = admin
|
|---|
| | | role = "#admin"
|
|---|
| | | role = "#notfederated"
|
|---|
| | | repository = repo1.git
|
|---|
| | | repository = repo2.git
|
|---|
| | | repository = RW+:repo1.git
|
|---|
| | | repository = RW+:repo2.git
|
|---|
| | |
|
|---|
| | | [user "hannibal"]
|
|---|
| | | password = bossman
|
|---|
| | | repository = RWD:topsecret.git
|
|---|
| | | repository = RW+:ateam/[A-Za-z0-9-~_\\./]+
|
|---|
| | |
|
|---|
| | | [user "faceman"]
|
|---|
| | | password = vanity
|
|---|
| | |
|---|
| | | user = faceman
|
|---|
| | | user = murdock
|
|---|
| | | user = babaracus
|
|---|
| | | repository = topsecret.git
|
|---|
| | | repository = RW:topsecret.git
|
|---|
| | | mailingList = list@ateam.org
|
|---|
| | | postReceiveScript = sendmail
|
|---|
| | |
|
|---|
| | |
|---|
| | | username=password,role1,role2,role3...
|
|---|
| | | @teamname=&mailinglist,!username1,!username2,!username3,repository1,repository2,repository3...
|
|---|
| | |
|
|---|
| | | #### Usernames
|
|---|
| | | ### Usernames
|
|---|
| | | Usernames must be unique and are case-insensitive.
|
|---|
| | | Whitespace is illegal.
|
|---|
| | |
|
|---|
| | | #### Passwords
|
|---|
| | | ### Passwords
|
|---|
| | | User passwords are CASE-SENSITIVE and may be *plain*, *md5*, or *combined-md5* formatted (see `gitblit.properties` -> *realm.passwordStorage*).
|
|---|
| | |
|
|---|
| | | #### User Roles
|
|---|
| | | There are two actual *roles* in Gitblit: *#admin*, which grants administrative powers to that user, and *#notfederated*, which prevents an account from being pulled by another Gitblit instance. Administrators automatically have access to all repositories. All other *roles* are repository names. 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.
|
|---|
| | | ### User Roles
|
|---|
| | | There are four actual *roles* in Gitblit:
|
|---|
| | |
|
|---|
| | | - *#admin*, which grants administrative powers to that user
|
|---|
| | | - *#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:
|
|---|
| | |
|
|---|
| | | - myrepo.git
|
|---|
| | | - RW+:myrepo.git
|
|---|
| | |
|
|---|
| | | This is to preserve backwards-compatibility with Gitblit <= 1.1.0 which granted rewind power to all access-permitted users.
|
|---|
| | |
|
|---|
| | | ### Personal Repositories & Forks
|
|---|
| | |
|
|---|
| | | Personal Repositories and Forks are related but are controlled individually.
|
|---|
| | |
|
|---|
| | | #### Creating a Personal Repository
|
|---|
| | | A user may be granted the power to create personal repositories by specifying the *#create* role through the web ui or through the RPC mechanism via the Gitblit Manager. Personal repositories are exactly like common/shared repositories except that the owner has a few additional administrative powers for that repository, like rename and delete.
|
|---|
| | |
|
|---|
| | | #### Creating a Fork
|
|---|
| | | A user may also be granted the power to fork an existing repository hosted on your Gitblit server to their own personal clone by specifying the *#fork* role through the web ui or via the Gitblit Manager.
|
|---|
| | |
|
|---|
| | | Forks are mostly likely personal repositories or common/shared repositories except for two important differences:
|
|---|
| | |
|
|---|
| | | 1. Forks inherit a view/clone access list from the origin repository. |
|---|
| | | i.e. if Team A has clone access to the origin repository, then by default Team A also has clone access to the fork. This is to facilitate collaboration.
|
|---|
| | | 2. Forks are always listed in the fork network, regardless of any access restriction set on the fork. |
|---|
| | | 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
|
|---|
| | |
|
|---|
| | |
|---|
| | |
|
|---|
| | | 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>
|
|---|
| | |
|
|---|
| | | %BEGINCODE%
|
|---|
| | | // 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
|
|---|
| | | %ENDCODE%
|
|---|
| | |
|
|---|
| | | ### Custom Fields
|
|---|
| | |
|
|---|
| | | *SINCE 1.0.0*
|
|---|
| | |
|---|
| | | **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 (<= 1.1.0) always verifies certificate hostnames, regardless of the *http.sslVerify=false* client-side setting. |
|---|
| | | You must do this because Eclipse/EGit/JGit (<= 2.1.0) always verifies certificate hostnames, regardless of the *http.sslVerify=false* client-side setting. |
|---|
| | |
|
|---|
| | | - **Eclipse/EGit/JGit**
|
|---|
| | | 1. Window->Preferences->Team->Git->Configuration
|
|---|
| | |
|---|
| | | - **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>
|
|---|
| | |
|
|---|
| | | ### Cloning an Access Restricted Repository
|
|---|
| | | - **Eclipse/EGit/JGit**
|
|---|
| | | Nothing special to configure, EGit figures out everything.
|
|---|
