gitblit/docs/01_setup.mkd

Gitblit WAR Setup

1. Download Gitblit WAR %VERSION% 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. Copy the WEB-INF/users.conf file to a location outside the webapps folder that is accessible by your servlet container.
   Optionally copy the example hook scripts in WEB-INF/groovy to a location outside the webapps folder that is accesible by your servlet container.
4. The Gitblit webapp is configured through its web.xml file.
   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
   NOTE: Make sure to change the administrator username and/or password!!

Gitblit GO Setup

1. Download and unzip Gitblit GO %VERSION%.
   Its best to eliminate spaces in the path name.
2. The server itself is configured through a simple text file.
   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
     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 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.
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.

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.

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.

1. Review the contents of makekeystore.cmd or makekeystore_jdk.cmd
2. Set your hostname into the HOSTNAME variable.
3. Execute the script.
   This will generate a new certificate and keystore for your hostname protected by server.storePassword.

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!

Additionally, if you want to change the value of server.storePassword (recommended) you will have to generate a new certificate afterwards.

Running as a Windows Service

Gitblit uses Apache Commons Daemon to install and configure its Windows service.

1. Review the contents of the installService.cmd
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.
Additional service definition options and runtime capabilities of gitblitw.exe (prunmgr.exe) are documented here.

NOTE:
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.
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
   

   Java Virtual Machine:
   C:\Program Files\Java\jre6\bin\server\jvm.dll

Command-Line Parameters

Command-Line parameters override the values in gitblit.properties at runtime.

--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)
--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

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. 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.
   

   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
   

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.
   %BEGINCODE%

   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

%ENDCODE%
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

Generally, upgrading is easy.

Since Gitblit does not use a database the only files you have to worry about are your configuration file (gitblit.properties or web.xml) and possibly your users.conf or users.properties file.

Any important changes to the setting keys or default values will always be mentioned in the release log.

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. Backup your web.xml file
   Backup your web.properties file (if you have one, these are the setting overrides from using the RPC administration service)
2. Delete currently deployed gitblit WAR
3. Deploy new WAR and overwrite the web.xml file with your backup
4. Review and optionally apply any new settings as indicated in the release log.

Upgrading Gitblit GO

1. Backup your gitblit.properties file
2. Backup your users.properties file (if it is located in the Gitblit GO folder)
   OR
   Backup your users.conf file (if it is located in the Gitblit GO folder)
3. Backup your Groovy hook scripts
4. Unzip Gitblit GO to a new folder
5. Overwrite the gitblit.properties file with your backup
6. Overwrite the users.properties file with your backup (if it was located in the Gitblit GO folder)
   OR
   Overwrite the users.conf file with your backup (if it was located in the Gitblit GO folder)
7. Review and optionally apply any new settings as indicated in the release log.

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

Repositories can be created, edited, renamed, and deleted through the web UI. They may also be created, edited, and deleted from the command-line using real Git or your favorite file manager and text editor.

All repository settings are stored within the repository .git/config file under the gitblit section.

[gitblit]
    description = master repository
    owner = james
    useTickets = false
    useDocs = true
    showRemoteBranches = false
    accessRestriction = clone
    isFrozen = false
    showReadme = false
    federationStrategy = FEDERATE_THIS
    isFederated = false
    skipSizeCalculation = false
    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 / _ - .
Whitespace is illegal.

Repositories can be grouped within subfolders. e.g. libraries/mycoollib.git and libraries/myotherlib.git

All repositories created with Gitblit are bare and will automatically have .git appended to the name at creation time, if not already specified.

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.

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.

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.

The users.conf file uses a Git-style configuration format:

[user "admin"]
    password = admin
    role = "#admin"
    role = "#notfederated"
    repository = repo1.git
    repository = repo2.git

[user "hannibal"]
    password = bossman

[user "faceman"]
    password = vanity

[user "murdock"]
    password = crazy        

[user "babaracus"]
    password = grrrr

[team "ateam"]
    user = hannibal
    user = faceman
    user = murdock
    user = babaracus
    repository = topsecret.git
    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...

Usernames

Usernames must be unique and are case-insensitive.
Whitespace is illegal.

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.

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 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.

parameter	value	description
realm.ldap.server	ldap://localhost:389	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).
realm.ldap.username	cn=Directory Manager	The credentials that will log into the LDAP server
realm.ldap.password	password	The credentials that will log into the LDAP server
realm.ldap.backingUserService	users.conf	Where to store all information that is used by Gitblit. All information will be synced here upon user login.
realm.ldap.maintainTeams	true	Are team memberships maintained in LDAP (true) or manually in Gitblit (false).
realm.ldap.accountBase	OU=Users,OU=UserControl,OU=MyOrganization,DC=MyDomain	What is the root node for all users in this LDAP system. Subtree searches will start from this node.
realm.ldap.accountPattern	(&(objectClass=person)(sAMAccountName=${username}))	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.
realm.ldap.groupBase	OU=Groups,OU=UserControl,OU=MyOrganization,DC=MyDomain	What is the root node for all teams in this LDAP system. Subtree searches will start from this node.
realm.ldap.groupMemberPattern	(&(objectClass=group)(member=${dn}))	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.
realm.ldap.admins	@Git_Admins	A space-delimited list of usernames and/or teams that indicate admin status in Gitblit. Teams are referenced with a leading @ character.

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 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.

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 lets you quickly add maven repository dependencies to your Groovy hook script.

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 Ivy 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.

%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

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 (<= 1.1.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. Key = http.sslVerify
     Value = false

• Command-line Git (Git-Config Manual Page)
  

  git config --global --bool --add http.sslVerify false

Cloning an Access Restricted Repository

• Eclipse/EGit/JGit
  Nothing special to configure, EGit figures out everything.

  https://yourserver/git/your/repository

• Command-line Git
  My testing indicates that your username must be embedded in the url. YMMV.
  

  https://username@yourserver/git/your/repository