MySQL on GitHub

Today MySQL is officially joining the GitHub community, with the launch of a beta GitHub repo for MySQL Server.

Why We’re Doing It

GitHub has become the place to be for successful open source projects; it has a large and rapidly growing user base, it is robust and fast, and it provides excellent tools for building and supporting vibrant open source communities. All this, plus the fact that lots of projects that are built on top of MySQL source code are on Github, meant that the choice was pretty obvious for us when we started looking for a new code hosting service.

This also means that we are switching our day to day development activities to use Git. The MySQL org is highly distributed, with many developers working from home and others working out of Oracle offices in almost every corner of the world, so it was a given that we needed a distributed version control system. Another requirement was that the system we chose had to have a large and active community around it; as we all know so very well, a large, competent and enthusiastic user base, coupled with openness, tend to make a system much more flexible, robust and better performing. Git fits the bill very well, with good performance, lots of useful tooling from the large community of Git users and a boatload of features that will make MySQL developers’ lives easier.

How to Get Started

Want to get stuck in?

The home of MySQL on GitHub is at, and here are the basics of using the repo:

Cloning over http: 
$ git clone 
Over the native Git protocol (requires SSH key on the GitHub server): 
$ git clone 
(The download size is ~ 410 MB)
Available branches: 
$ git branch -r 
origin/HEAD -> origin/5.7 
Checkout of MySQL 5.6: 
$ git checkout 5.6 

You can find a lot more in depth information in GitHub’s excellent documentation.

So, What Does ‘Beta’ Mean?

It means that we may change things around on GitHub for a while still, so we encourage everyone to exercise a little bit of care.

Switching source code management system is a significant change for any development project. When you have hundreds of developers and contributors, lots of surrounding infrastructure for build, test and publication of source code and binaries, with processes to coordinate all of this, and when halting development for any period of time is an absolute no-go, the scope and complexity of change becomes huge.

This means that we are not quite done yet with our switch to Git. So the code we are publishing on GitHub now is an export from our existing Bazaar source code repo. That will change when we switch development to Git; at that point our GitHub repo will become a copy of our internal development Git repo. When we do that switchover we will have to break continuity, so that if you have created your own forked MySQL repo before the switch, you will be unable to pull code updates to that repo after the switch. You will have to fork again, export your commit history from your old fork and apply that to your new fork. We will of course make sure to give a heads up when that switchover point approaches.

So the “beta” label should be taken to mean that the MySQL repo on GitHub is a correct and fully usable Git repo, but we do reserve the right to tweak and tune things for a little while, and at some point in the near future, when we go out of beta, we will need to break continuity.


A basic question we expect to see from the GitHub community is “How do I contribute back?” For some projects, it is a simple matter of issuing a pull request to ask the upstream project to review and possibly merge in the changes you are contributing. In our case, we need to ask for a little bit more. The MySQL Server Team blog has a good step by step guide for those who want to contribute, and we encourage those who are interested to head over there for more information.

We will look for ways to better connect our contribution process with our presence on GitHub, and if you have suggestions, please let us know in the comments section below. For now, we promise to make sure that pull requests get a response with information on how to contribute “the right way”.

Let me end this posting by saying that we really hope that our presence on GitHub will be useful to everyone with an interest in our code, whether for their own development or simply as a way to keep up with the rapid pace of MySQL development in general. I would also like to thank the GitHub team for welcoming us into the fold, in particular Sam Lambert, who has been a very helpful guide along the way.

And if you have suggestions for how we can optimize our usage of GitHub, or if you should encounter issues with the repo, please let us know in the comments section.

Happy hacking!

Yngve Svendsen

About Yngve Svendsen

Yngve Svendsen has been part of the MySQL organization since 2008. Based in Trondheim, Norway, he is Senior Director of MySQL Engineering Services and responsible for Release Engineering, QA and development lab IT services for the MySQL org at Oracle. Back in the mists of time he majored in mathematics before the dot com wave swept him into the devops field, first at the database startup company Clustra Inc. and then for Sun Microsystems. In 2005 he joined the Dark Side by becoming a manager in Sun's Database Group which was merged into the MySQL org when Sun acquired MySQL in 2008.

13 thoughts on “MySQL on GitHub

  1. Great to see MySQL on GitHub 🙂

    Puppetlabs is also using github. They have a automated method of checking if the contributer has signed the contributor agreement. Something similar could be done for OCA.

    1. Hi, Daniël.

      Thanks for a very interesting tip. We’ll follow up on that once we are done with our internal Git migration, which should hopefully be fairly soon.

  2. A couple of notes on the conversion:
    – There may be some bzr revisions that have different committers to authors, you may want to ensure those are translated properly (I know we had some in Drizzle, not sure about MySQL, I can’t remember).
    – you possibly want to go through and normalize the committer names, as currently, things are *very* odd. I did this in for all of the authors I could find, and you could just use that same mapping. This makes it much easier to track who-wrote-what (both from a development PoV as well as analysis of who is/has been working on what).
    – if you copy my git repack command line, “git config core.compression 9; git repack -AdfF –depth=100 –window=500” you can probably get a smaller repository, making initial branching much quicker.

    1. Yes, I see how this can be slightly unclear right now. For the time being, we have two places where we export our code: Launchpad and GitHub. Launchpad is the official external repo for MySQL, while the GitHub one is currently marked as being in a “beta” state. The trees in both places are supposed to be identical, but until we finish moving our internal day to day development from Bazaar to Git, breakage might possibly occur in the repo on GitHub. We’re trying hard to avoid hiccups, but there are no guarantees.

      When we complete the internal switch to Git, we will make the GitHub repo our official external repo, replacing Launchpad.

      And thanks for pointing out that page in the Internals manual, which is in general woefully out of date. We need to fix that page at least, for when we switch officially to GitHub.

      1. Hi Yngve!

        It is not only the “Internals” manual, it is also the “Reference” manual:

        Can external code readers safely assume that the github tree will contain the sources used to build a GA release (MySQL 5.5 or 5.6), and what would be the possible delay from the release date to github having received those sources?

        and thanks for all your work on MySQL!

        1. Hi, Jörg.

          It’s been a while. Thanks for the kind words and pointers. We’ll make sure things get fixed soon.

          So, when we make GitHub our official channel for source code posting, currently planned for the end of January, we will follow the same procedure and schedule as we currently do on Launchpad. Basically, as soon we have merged back and tagged, we will push the code to GitHub. Should not take more than a day or two unless we hit some unexpected merge issue.

  3. Thank you Yngve, now it understandable.

    While reading MySQL echo system in detail , I’ve few queries , what will be the best place to ask those ?

    Like for example on MySQL documentation of “create table” , it say you can define Data Directory , Log Directory and Tablespace .

    While on Create Tablespace , one can also define its default directory , so if I define /xyz/mysql/mydb for Tablespace TS1, and while create table T1 I define data directory /abc/mysql/mydb and also define its tablespace TS1, what directory will take precedence ? where will be the actual directory will created?

    Tablespace or data_directory ?

    Thank you.

    1. Hi, Khurram. Sorry for the somewhat late response.

      There are numerous community mailing lists where questions can be asked, but the first place to go to should be the MySQL forums at, where you will find a lively community and quite probably someone who would be willing to answer your questions.

Comments are closed.