New in Git Fusion 2013.2: Support for Git Tags & HTTP
Git Fusion’s goal is to give Git and Perforce users an uncompromised experience using the version control tool of their choice while still being able to work together seamlessly. The 2013.2 release gets us closer to that goal and, at the same time, makes Git Fusion easier to administrate and use.
Introducing Support for Git Tags
Prior to this release, any tags that were pushed to the Git Fusion service would only be preserved as long as the Git Fusion repository was intact. Now tags of commits are preserved in the Perforce depot, which allows them to be rebuilt if the need arises, as in the case of repopulating the Git Fusion repository. The commit tags can be either annotated or lightweight; both are preserved equally well.
Tags in Git Fusion can be added or removed. Removing tags deletes both the reference in the repository as well as the associated object in the Perforce depot. Any changes to the tags are automatically shared between multiple Git Fusion hosts, so no special care is needed to maintain consistency.
Git developers may be aware that Git tags can target any Git object, including commits, trees, blobs, and even other tags. Git Fusion can only preserve tags of commits that are pushed to Git Fusion. Why is this the case? When pushing objects to a remote Git repository, the client is in control of what is delivered to the server. If the client is pushing only tags (as in git push --tags), then only those references are provided to the pre-receive hook, which Git Fusion uses to convert Git commits to Perforce changes. Since Git Fusion is only notified of the tags, it does not know about any other objects that may or may not be related to those tags (and doing so is a costly operation of walking the entire Git object graph). As such, Git Fusion can only be sure about commits that it has seen, either in an earlier push, or in the current push. Thus only tags of commits are preserved in Git Fusion in order to ensure consistency across clones, and avoid dangling tags for which the target is not available.
Say Goodbye to SSH Keys (If You Want)
In the latest release of Git Fusion, the option of using HTTP instead of SSH as the transport protocol is now available. There are two basic requirements for the HTTP support to function well: one is running the Git Fusion service in a web server that fully supports the HTTP and CGI standards (RFCs 2616 and 3875 respectively); the other is that the REMOTE_USER environment variable is set to the name of the authenticated Perforce user that is performing the push. See the documentation for more on configuring Git Fusion with Apache.
Using HTTP instead of SSH has one shortcoming: a standard Git client does not display the response from the server. Normally this would not matter since the client is only interested in the raw data being delivered from the remote. However, if an error occurs, or the developer wishes to invoke one of the Git Fusion special commands (e.g. @info or @list), then another HTTP client will be needed to see the raw response. For example, if the client attempts to clone a repository that does not exist, a 404 is returned from the server, along with a detailed error message. The Git client discards this response and instead displays a message about running the update-server-info command on the server. However, the actual issue is the requested repository does not exist. Hence a dedicated HTTP client such as cURL is needed to see that message and diagnose the issue.
Have It Your Way
In this release of Git Fusion, an option is included to specify an executable script or binary be executed for each pushed commit. If this script rejects any commit, the entire push is rejected. This allows for custom policy enforcement, and ensures the depot and repository are in a consistent state.
2013.2 brings some great improvements, but we aren’t resting on our laurels; 2013.3 is tight on its heels bringing submodule support and more. As always if there are features you want, head on over to P4IdeaX and share them with us and the rest of the Perforce community.
This article first appeared in the Head Revision, Perforce's monthly newsletter.