Make sure you use the git protocol (not http) and include the trailing slash.

Can you use develop.git.wordpress.org for core development? Yes! For all practical purposes, the SVN and Git repositories are now equals. Pick your poison; use whatever you’d like for all your development and deployment needs.

For creating patches: If you’re into the command line, simply use git diff — to be specific, git diff --no-prefix is ideal. This format is easily applied with patch, just like SVN diffs. For more, check out scribu’s post on contributing using git. Might also be a good time to plug grunt-patch-wordpress, a work in progress — help make it awesome, if you can.

With this mirror, we’ve applied some lessons we learned from previous experiences:

Tags for major releases receive an extra .0 (“3.8.0″, not “3.8”), making them compatible with tools requiring semver-like version numbers, and allowing branches to have their own namespace (“3.8″, not “3.8-branch”).

Committer data is pulled from WordPress.org.

The SSL versions of the SVN repositories are used.

Note that these Git repositories have different hashes than anything currently mirrored on GitHub. We never did break these hashes as promised a year ago. Next steps will be to figure out how to best mirror these to GitHub (and replace what’s there), which is complicated by now having old and new repositories for core development. Additionally, I’m sure we’ll find at least one glitch in this in a matter of a few days, so consider the next week or so a beta test.

Edit: Well, I mentioned the next week would be a beta test. We found an error (that didn’t take long) in how authors got synced over, so we’ll be breaking the hashes tonight.

There are a lot of other repositories on WordPress.org not yet mirrored. Notably: plugins and themes. These are massive multi-project repositories and will require a bit more investment.

To clarify, as I think I chopped out an sentence when editing this: It’s still a read-only mirror. “For all practical purposes” was meant to apply to everyone but committers. So for the committers to these repos that want to use Git, you’ll still need to use git-svn, for the moment.

Thank you. I did actually have that Github repo watched but its description makes it clear that it is just a mirror (from svn) and not a place where anyone can submit their contributions to. What’s the plan on accepting pull request directly on Github, if any?

If you or your tools want to use Git, you should be able to. If you or your tools want to use SVN, you should be able to. You could think of it as a desire to be VCS agnostic. Whether one commits to SVN or pushes to Git is ideally a decision that should rest with individual plugin developers. Or for the case of these repos, the group of committers. When the infrastructure is there for this, of course.

Good question. I wasn’t necessarily planning to have the i18n repository mirrored, given we’re trying to end our dependence on it (and that it’s a massive, multi-project, unusual repo). But I forgot about the POT directory. People still use that?

The post makes clear that these operate over git://. The reason is this is simply being served using git-daemon. We’ll work on support for http-based communications in the future. If your organization blocks git and requires http or https, you can easily mirror this yourself for the moment (and stay tuned for these to be pushed to GitHub).

Sorry, I meant the hashes of these git.wp.org repositories. We haven’t figured out what the plan will be for the GitHub repository yet. We already signed off on breaking those hashes in the past, but I don’t know how feasible that is. Options include moving wordpress/wordpress to wordpress/wordpress-build (and then optionally breaking the hashes and having it mirror core.git) and then adding a new wordpress/wordpress-develop for develop.git (one downside being the watchers and stars wouldn’t carry to the new “canonical” repo, but not a big deal). Suggestions welcome.

Omg so exciting! I’m really stoked to hear that WordPress is moving in the direction of fully supporting Git and maybe eventually GitHub.

I have a question that I hope isn’t too newbie for here. I understand the issues above with GitHub and I can handle using the command line. However, I’m new to open source contributions and would like to start with working on small WordPress bugs. I have a GitHub profile and have installed GitHub’s software to my Mac to keep track of my forks locally. So I have two questions:

1) For my local purposes, does this mean I could theoretically keep track of my own work in the GitHub software, even though I can’t actually use GibHub to submit patches? If yes, would I just follow scribu’s instructions through step 3 (make a feature branch) and then locally save the clone of the WordPress source files so my GitHub software can see it?

2) For “having things on my GitHub profile purposes,” once I’ve followed to command line steps to submit my patch, would I just use the usual process to send the patch to GitHub but not actually create a pull request?

Right, you can still create a feature branch, commit to that branch, and push that branch to your own fork on GitHub. You just would not actually create and send a pull request. Note that you can also get a patch from GitHub by adding “.diff” to the end of any commit URL.

A few years ago, I started publishing a mirror of WordPress on GitHub. It was subsequently promoted to WordPress/WordPress. What I neglected to do, however, was provide an appropriate authors.txt file, until recently. That means that earlier commits are attributed to dummy e-mail addresses and as such cannot be associated with user accounts on GitHub. Considering the recent introduction of contributions on GitHub, this seems a shame. Also, if we were to move to Git in the future, we would probably want our official mirror to have the best possible data.

Proposed

That we re-run the git-svn import with a proper authors.txt file.

Upsides

We’ll have a proper Git mirror with good and consistent author data, that we can, if desired, use for a future migration to Git. Commits will be properly attributed in GitHub.

Downsides

This will break Git history. If you have a Git checkout of WordPress, either standalone or in a submodule, that’ll mean that you’ll have to rebase your master branch off of origin (or even better, blow the whole thing away and re-clone).

Another thing I’d do is contact everyone in that file and get them to doublecheck that we have an e-mail address that they’re likely to control for life. Probably best to use e-mail at a personal domain, if they have one, instead of Gmail or a company e-mail address that they might lose in the future.

What’d be really cool is if we can get the props parsed so that git lists the commit author as whoever was prop’d, and the committer as the person who actually committed it. AFAIK, that’s not possible without a complicated script though.

That would be cool, but I really can’t even think of any way to do something like this with the current repo as is without amending commits after the initial clone, which would be extremely resource intensive and could take weeks to do. Given that and the work involved with integrating the same process into the mirror updates for future commits as well, I would just say forget it.

While parsing props like this would be cool I don’t think it would accurately reflect the way our process has worked and I would much rather put effort into collecting the props to commit data into a format we can integrate into the WP.org profiles more easily.

I started on this a while back but haven’t finished yet, what I’m mostly missing is an 100% accurate props extraction method.

At the moment, there’s basically two forms of commits with props: 1) the committer is merely committing a patch that was on a ticket (this is where we’d want to split author/committer); and 2) the committer is writing the patch with inspiration from someone (we’d want author = committer in this case).

As far as I’ve seen, 1 seems to be the much more common case, but 2 is fairly common too. It could be a problem. (Regarding effort, it’s relatively simple using git filter-branch, so that shouldn’t be much of an issue.)

I think you’re already aware that I actually use my own clone of the WP repo partly for this reason, but also because it’s nice having branch and tag names that are exactly the same as the branch and tag names in SVN. It would be nice if those were fixed up as well if you do this.

Yeah, if we’re doing this, we should take the time to iron out all other niggling issues. Would love to have your input on that. My issue with branch names is that it create ambiguous references. So if you go to checkout “3.5” it will check out the 3.5 branch. In order to check out the 3.5 tag, you need to do git checkout tags/3.5. Not the end of the world. Might be worth it to get everything cleaned up.

Hey, maybe we can just rebase me and retroactively teach me all this Git and Git-SVN subtleties! Just don’t push me, man.

Mark does already do this, which is why the branches are named #.#-branch.

Anyway, git does assume you wanted the branch instead of the tag, but that’s almost always the case for me anyway. I almost never checkout the tags, and I don’t think anyone else does either (definitely not with SVN either). In the 5 months or so that I’ve had my mirror running, this has never gotten in my way once or annoyed me in any way.

it would be good, i have been asking /systems guys to install git as revision control, but it seemed only someone in some driver’s seat could ask for stuff there! git is fast, no problem if it breaks for a while! thanks for this! full ahead flank

That will change the commit hashes, since the author/committer is stored as part of the commit object (which is used to create the hashes). There’s no way (by design) to change these after the fact without doing this.

I think it would be a great step forward. Drupal also used to be in SVN and switched to Git a couple of years ago. It was entitled “the great git migration” and took almost a year to design, layout and implement the whole process but it was worth it. Using Git has many advantages! I believe that breaking the history is worth it in the long run.
Sure it might be a bit inconvenient at first, but I believe that it could really give a new boost to WordPress development.

To clarify: this isn’t about moving WordPress to Git, this is about fixing up the Git mirror of the SVN repo. This is a step we’d need to take if it was decided to move WP to Git, but it’s not the main goal.

Git is always a better option but needs carefulness on individual basis. Many options for an user is to download. The developer is getting the option to create a better documentation or guide. Cloning is not really difficult.
There are basic problems too, a good guide is needed for increasing awareness.
As practically we are not shifting, there is time.

I’m all for the update in order to improve the history and prepare for a possible move to git. I’m wondering whether you plan to send a little message (could it be automated?) to all those who have forked the repo on github?

GitHub removed their private messaging feature, so I’d have no automated way of notifying everyone. This doesn’t concern me so much as we don’t accept pull requests on GitHub, so it’s not like their forks are functional in that way. I also think a lot of people fork repos and never update it from the upstream again. So they probably wouldn’t notice. And it’s easy enough to destroy it and refork it.

What I was considering doing was putting a note on our project description on GitHub, for the next few months, providing a link to a post that explained what happened and how to resolve the divergent Git history.

As the response was overwhelmingly positive (even from some of you who are traditionally serial devil’s advocates), I think we’re going to move forward with this. Thanks, all, for your feedback.

What I’ll likely do it consult with various people (@bpetty, notably) about implementation, doublecheck the e-mail address in my authors.txt file (recommending that everyone use addresses at personal domains that they’re likely to control indefinitely), and then push out a WordPress-Fixup repo for people to audit, before pushing the new history to the WordPress repo.

Confirming email addresses used would definitely be a good idea. I think a large portion of what you have now originally came from my list, which was meticulously put together from scouring plugin readmes, wp-hackers archives, and personal sites for publicly visible addresses since, at the time, I knew I wouldn’t be able to simply pull them from WP.org accounts used to make the commits (which would likely be the best source, aside from contacting everyone individually).

There’s a SVN-module in git. With git-svn you can pull changes from a master-subersion-repository and push to it while having all benefits of a git repository. These include cheap and easy branching and merging, being able to to commit, branch merge, whatever without a connection to the svn-server and – what i like the most for wordpress – have the opportunity to branch and commit without commit-privileges in the subversion repository. With this people can do little commits local and then let the one that manages the master-git repository pull from them and commit to svn.

Having a GitHub git repository can give wordpress a lot of momentum, there are a lot of wise people on GitHub.

May 15th was a suggested release date (When all dates were pushed back 2 weeks), That has obviously passed however. There is no firm date for release yet (that I’m aware of), it’ll be released shortly hopefully..