GitHub fully operational again


GitHub outage latest for around 23 minutes and now the site has resumed normal stable operations. and his users have not been impacted by the GitHub outage, everything went smoothly and the cache TTL extension avoided any negative effects on our systems. Replication to GitHub resumed smoothly without any misalignment caused by the the outage.

Will this be the last GitHub outage? Have they learned how to implement effectively DB roll-outs with Continuous Delivery practices?

It would be very interesting if Shawn Pearce could put together a presentation on how Continuous Delivery is achieved for Gerrit Code Review at Google, avoiding downtime even during DB upgrades and roll-outs. Possibly GitHub could be inspired by us 🙂

GitHub outage started … hopefully won’t be long :-)

GitHub.outage.startedAs previously announced,  GitHub service outage has officially started. is available as usual and sign-in is working, thanks to the an extended cache TTL set to 2 days. If you have signed in over the past two days, your cookie will still be valid and your group ownership / permissions are cached on our systems.

Please remember that some of the other non-cacheable services won’t be available:

  • Sign-Up for a new account
  • Import of a GitHub profile
  • Import of a GitHub repository or pull request
  • Replication to GitHub

You can still use the Gerrit Code Review functionalities as normal, including review Web GUI and git push/pull over SSH or HTTPS.

Once GitHub will be back on-line, we will reschedule an extra maintenance replication to make sure that all Gerrit changes are replicated back to GitHub.

Thank you for your patience and in case of any issue please report to

GitHub Scheduled Maintenance – Saturday 3/21/2015 @ 12:00 UTC


GitHub planned outage

GitHub announced a scheduled downtime of its API starting from this forthcoming Saturday, 21st of March 2015 from 12PM UTC … I have to say that this is really the first time and I am quite surprised. I have always considered GitHub as one of the best examples of continuous deployment and feedback, allowing the transparent roll-out of dozen of changes every week; however sometimes even “The Rich Also Cry”.

What are the implications of this outage for uses the GitHub API for the following operations:

  • Sign-Up and Sign-In to Gerrit Code Review GUI
  • Import user profile, repositories and pull requests
  • Gerrit groups lookup
  • Replication using GitHub OAuth

As all the GitHub API would return 503 (Service Unavailable) the basic Gerrit Code Review functionalities could be eventually impacted.

How can we minimise the impact?

We will be rolling out longer cache TTL and cookie expiry times on Friday 20th of March on Gerrit Code Review, allowing to keep existing sessions for a much longer time up to 2 days validity. Similarly the Group and Accounts caches TTL will be extended in order to fill the GitHub API blackout.

And what about replication?

Whilst we can minimise the impact on Gerrit Code Review which is under our control, we can do little about GitHub availability: the commits pushed to will be “parked” until GitHub services will be resumed again.

They will still be accessible to your Team but only through the clone URLs.

What should I do when GitHub services will be resumed?

GitHub has not notified yet the length of his maintenance window but you will be able to receive notifications on its status on and we will notify the progress and the impact on our services on, Twitter @gitenterprise and Facebook on

Once the GitHub services will be back and fully operational, we do suggest to sign-in and verify the replication status of your repositories to GitHub, checking the SHA-1 of your branches on against the corresponding ones on GitHub.

Example on how check the replication status of myorg/myrepo:

$ git ls-remote | \
  egrep -e "(heads|tags)" | awk '{print $2"\t"$1}' | \
  sort > /tmp/myrepo.gerrit
$ git ls-remote | \
  egrep -e "(heads|tags)" | awk '{print $2"\t"$1}' | \
  sort > /tmp/myrepo.github
$ diff /tmp/myrepo.gerrit /tmp/myrepo.github

What should I do to resync the repositories?

First of all you need to establish which one is the “source of truth”. If you have been using as main code review, then the answer is always
In order to resync your GitHub repository, you just need to manually pull from and push to

Example on how to resync myorg/myrepo:

$ git clone --mirror 
$ cd myrepo.git
$ git push --all --tags

What should I do if the push to GitHub fails?

There is not a unique answer to this question: if the push fails it means that your and repositories started diverging. This happens when people pushes directly to GitHub without going any Code Review, which is potentially possible if you have left the permissions doors wide opened on GitHub.

My suggestion is always to check what is in GitHub that has not gone through Gerrit Code Review and, if possible and does not create conflicts, pull that set of commits into your repository.

Example of pulling changes from a GitHub branch (e.g. mybranch) that are not contained in

$ git clone 
$ cd myrepo && git checkout mybranch
$ git pull mybranch
$ git push origin mybranch

Questions? Doubts? Problems?

If you have any questions or you need any assistance during the outage because you are experiencing problems, feel free to contact our customer support at or tweet us at @gitenterprise.

Alternatively for any Gerrit-related problems, the best free source of information is always the Gerrit mailing list at!forum/repo-discuss.

Gerrit moves into Cloud IDE space with in-line edit

Gerrit Code Review has begun the Ver. 2.11 release cycle and the first release candidate been released this morning on

Entering into the battlefield

Gerrit is entering for the first time into the field of Cloud based IDE integrating a Browser-based editing functionality into the code review lifecycle. For the very first time you are just a couple of clicks away from a review-edit-submit turnaround: see below the additional icon to access the functionality from the Gerrit change screen.


What is in-line edit and how can I use it?

As this is a brand-new functionality with a complete new UX, a new dedicated page has been published to guide through the new functionality.

You can experiment today the in-line edit by creating a new project on GitHub and sign-in to The new turnaround is quick and the flow is splendid ! This has been a masterpiece in collective code ownership and review of the Gerrit Team; this feature has been lead by David Ostrovsky after a series of early betas shared and discussed collectively.

What else is included in Gerrit 2.11?

A lot of new enhancements are coming, mainly related to the improvements of Gerrit REST-API to support this new feature.

The full list of changes can be accessed at

Where is Gerrit heading to?

We foresee a near future where Gerrit becomes the central hub of the code-review and integration workflow, together with a CI engine such as Jenkins. It has recently proposed a new build of Gerrit without a GUI and exposing its review capabilities in headless mode: the presentation logic will then be implemented by the various UX plugins integrated with other IDEs.

Should this scenario materialise as future of Gerrit, we will soon see other UX that will expose the power, flexibility and scalability of Code Review system in a brand-new HTML5 or native experience.

The IntelliJ and Eclipse plugins are already a reality of this, but more will come and I bet they will be more focused on the Cloud IDE use-case.

GitEnterprise new face and new mission

Welcome to the new face of !

GitEnterprise is different, not only in his new external facing web-site but also deep inside in his mission and focus.

We have been providing cloud and hosted services powered by to provide a superior support for repository management, users and groups security and full audit-trail for around 2 years: now is time to make a bit leap forward.

One size does not fit all enterprises.

Can one solution be good enough for companies of all sizes ? We thought that we could build that solution and we started proposing our product in both hosted and cloud deployments for all our customers: over 7000 users registered to and created more than 10,000 repositories.

First phase of Git adoption is very much about discovery and has been a straightforward way to explore some enterprise-features such as role-based access control and branch-level security.

Once companies become familiar with Git and its usage in the Enterprise, the adoption really starts with the identification and exploration of the functional and ICT Security requirements needed by the organisation: different companies do have different requirements and integration with different systems.

Individual contractors.

The smallest of the Enterprises is the one-man-band where a single contractor is engaged by different companies for different projects. No specific requirements are needed other than private repositories with regular security and backup; Git Server is best hosted in the Cloud as minimises maintenance and operations costs whilst reducing risks of personal hardware failure.

Even though could be a cost-effective solution, it is possibly too complicated as RBAC and branch-level security are not needed and could be seen as repository administration burden.

We designed a “all-in-one” Git Server solution to combine ease of administration and personal security and confidentiality: his name is Git-in-a-box and requires no installation or administration, just download and use it.

Hosted: get Git-in-a-box and execute on your favourite Server to have a fully features Git Server without hassles.

Cloud: Git-in-a-box can be used in any private Cloud Server and can use any sort of Cloud storage backup. When a FREE Cloud Solution is required, the only choice on the market is that offers privacy and space at no charge.

Small to medium Enterprises.

Teams are typically co-located in a single Office and additional requirements start to become recommended if not mandatory depending on the industry sector.

Most companies can still have a Git Server hosted in the Cloud without breaking any specific company policy whilst others such as Finance Software Development companies have stricter requirements to address their internal auditing constraints.

Cloud: when cost reduction is the main focus and source-code is not subject to strict ICT Security requirements, can be a good compromise as it provides 10-users / 1 GByte FREE Subscription with added Role-based Access Control and Web-based audit-trail. Security administration is easy and users can be self-provisioned and invited to join the company domain later on.

Hosted: for small companies without specific security requirements, Git-in-a-box is still our favourite choice of simplicity and functionality. Companies working in the Finance sector anyway have additional ICT Security requirements that involve compliance with SOX / PCI regulations. GerritForge is a cost-effective solution to provide governance, audit and integration with existing ICT Security assets such as LDAP User-registry and password enforcement and producing audit-trails for compliance inspections and reports.

Large Enterprises.

Teams can be even huge and distributed over the globe: they include developers with different skills-set and level of maturity of the adoption of Git as SCM tool. Most of them are possibly coming from a Subversion or SourceSafe background and need a more user-friendly and safer interface to Git.

100% pure Cloud hosting is typically not an option whilst some of them may want to use a more flexible hybrid-cloud model combining a traditional data-center hosting with additional private clouds located in remote geographical locations to reduce latency on remote sites.

The following key requirements become mandatory for a corporate adoption:

  • Integration with Corporate User-registry such as corporate LDAP and Directory Services.
  • Single-Sign-On with existing authentication system and credentials.
  • Reuse of existing Corporate roles in the definition of the access control to Git repositories.
  • Git over HTTP/S for SSL and X.509 Certificate validation.
  • Full tamper-proof audit-trail of every operation triggered either via Web UI or Git client.
  • Delegation of control across your organisation.
  • High-availability of both Web/Git Services and data-storage.
  • Multi-site replication across all the Corporate offices.
  • 24×7 Support on the full Git stack.
  • Existing rock-solid user base and Corporate reference in the same Business area.
  • Integration with existing Corporate Workflow and Application Lifecycle Tools

Git was not designed to fulfil all of those Enterprise requirements, most Cloud or Hosted Services such as GitHub:Enterprise or Atlassian Stash provides coverage for only some of them such as LDAP integration and could be accepted in some departments with reserve from Corporate Security. and Git-in-a-box are definitely not the solution either as do not support full multi-site replication or workflow and ALM integration.

The only solution on the market is Gerrit Code Review: it has been designed and implemented by Google for the distributed and collaborative development of the Android OS, based on ashes of Guido Van Rossum’s experiment named Google Mondrian Code Review.

Gerrit Code Review is the only Git Enterprise tool adopted on a large scale by Companies such as SONY, Garmin, Qalcomm, SAP, Intel, HP, Deusche Bank and the list is growing on a daily basis.

Starting from Gerrit 2.5, announced @GooglePlex in Mountain View in November 2012, Gerrit is now extensible and can be integrated then with other tools and issue-tracking systems. We demoed the integration between GitBlit and Gerrit whilst providing full access to the OpenSource community to our Atlassian Jira integration.

GerritForge hosted is the Enterprise version of Google Gerrit Code Review with all the additional Enterprise Integrations you need to provide RBAC, Auditing and Application Lifecycle and Workflow.

GerritForge added the “missing pieces” for plugging it into a Corporate Environment:

  • Issue tracking association and enforcement
  • Workflow definition and automation
  • Tamper-proof audit-trail
  • 24×7 Support on the full Git and Gerrit software stack
  • Single-sign-on and 3rd party authentication plugins, such as CollabNet TeamForge.
  • Formal native packaging and installation procedure.
  • Access to ad-hoc patches for production issues even on older branches and releases.

We do believe so much in Gerrit that we have rebuilt all our product offering using Gerrit as foundation:

Git-in-a-box is a Gerrit 2.5 engine with an HTML5 / RESTFul API layer to provide ease-of-use and plug&play installation. is a Gerrit 2.2.2 engine with a JavaEE WebUI for automating common administration tasks.

GerritForge is Google Gerrit, with the same core code-base and version numbering.

Want to know more on Google Gerrit ?

For an initial introduction, the Google Gerrit Code Review Wikipedia page is the best place to start.

More detailed Wiki and project information can be found at Google Gerrit Code Review home page.