On Tue, Dec 13, 2011 at 8:44 AM, Chad <innocentkiller(a)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`
\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