On Tue, Dec 13, 2011 at 8:44 AM, Chad innocentkiller@gmail.com wrote:
Hi all,
As some of you are probably aware, we've got a test repository converting phase3 to git up and running on gerrit. You should be able to clone by
`git clone https://gerrit.wikimedia.org/r/p/test/mediawiki/core.git%60
\o/
- The revision graph is crazy. svn:mergeinfo is unreliable and we're pretty
much unable to build a cohesive history without a *lot* of manual labor. Right now I'm thinking of just dropping the mergeinfo so the branches look like linear graphs cherry picking from master. Not perfect, but less annoying than now.
I'd tend to agree. Subideal but at least manageable, especially since we've usually been pretty good about saying which revs we merged in the commit summaries.
But yay progress! Clone it. Try it out, see what works (and what doesn't). I'll try to get the permissions sorted later today so we can go ahead and try some test pushes (and merges).
It's taking a few more minutes than I expect for the initial clone (though that's usually not performance-critical); of course since there's a lot more data in there than a SVN checkout I don't mind so much.
Final checkout sizes: * SVN trunk/phase3 only: 145M * git core, all branches with full history since a 2003 code reorg: 198M
Niiiiiiice!
Release branches from 1.1 to 1.18 are present... no individual release tags visible though. Did we figure out how to get those done?
History (including 'git blame' view) seems to have transferred most contributors' identities over nicely, using @users.mediawiki.org fake addresses and adding realnames.
As viewed in gitk, branch points off of master are visible though as noted the various merges don't preserve much data. Oh wells!
Things we still need to do:
- Make a git-setup like we've done for the other git repos. This will
setup your environment/hooks/etc for you.
- Figure out our WMF branching/deployment strategy, since we're very SVN-
centric right now with this.
... and extensions. Whee! ;)
WMF branching/deployment should actually be a lot more git-friendly, since we can pull in the entire REL1_18 or REL1_19 or whatever into the deployment branch in a single command instead of cherry-picking every one. The key is making sure we've signed off of them so we know what's going into release, naturally. :)
Merging individual fixes into the release branch would first be done by cherry-picking, most likely.
-- brion