Jelmer just pinged me to show me a new fangled Mercurial plugin. Thats right folks – pulling and pushing between Git and Mercurial! It uses the dulwich library that I worked on with Jelmer (was the basis for my “git serve” crack and is also used for pushing and pulling between Bazaar branches and Git with bzr-git).
Coolness.
I look forward to seeing some new dulwich patches (they are using a patched copy right now).
When GNOME SVN was migrated to Git all your commits were attached to a generated e-mail address in the form username@src.gnome.org.
If you have a GitHub account you can go to your settings and add that e-mail address. Now all the old commits you made will be associated with your account when viewed on GitHub. If you’re a fan of the cute GitHub graphs, you’ll love this too.
A couple of days ago I was pondering DVCS whilst wandering along an icy road. Not focusing on the ice proved disastrous. My right foot flew forward and i landed flat on my ****, much to the amusement of my fellow codethinkers. My head bounced off the tarmac and my elbow hit.. well who knows, but my elbow ended up pretty damn swollen. The day after brought little mercy – I seemed to have pulled muscles i didn’t even know I had and looking far left or right proved challenging, as did the simple act of putting my bag over my shoulder. Difficulty sleeping followed.
My point is, all this talk of DVCS caused me physical harm. Discussion considered harmful, lesson learned.
A couple of interesting points were raised about the git-serve bridge which I would like to answer, regardless of what infrastructure GNOME migrates to. I should have been more clear from the start, but the bulk of the work to implement the Git protocol is happening in an upstream project called dulwich. Theres no relation to Bazaar, and might be a nice library for anyone doing Git work in python (it doesnt need to spawn git processes to operate). The code there is based on some earlier work by James Westby and its current maintainer is Jelmer Vernooij. Any code for the git-serve mapping between Git and Bazaar is getting added to the bzr-git plugin, and again i’m working with Jelmer.
I’ve written some basic responses to the common gut reactions on the Bazaar wiki.
In the context of GNOME, a more interesting question was about how to merge branches from people not using GNOME infrastructure and a different VCS to the maintainer. First of all, why arent they using us? But one interesting thing i’d like to see is a code review system with tight VCS integration. For example, using dulwich to allow people to push a branch to review board and convert it into a review automatically. (The Git protocol will send only the commits that need to be merged). Anyone can push, no plugins or setup needed by the contributor. Then we can allow people to land a merge from review-board in the browser, or merge from review-board into their local branch or even request buildbot test the branch first. git:// is a protocol. We implement lots of other protocols in the freedesktop world, lots of them far more complicated, lots of them much less open. So this doesnt scare me. Its just an efficient way of swapping patches. And of course we can reuse bzrlib for supporting Bazaar.
Most points that have been raised have a valid counter-argument if you approach them with a “we can” attitude, but going over them would likely lead to more ice slipping. I will be at FOSDEM, be sure to bring a stick.
Even if we don’t use Bazaar (and dulwich) as the platform for our core source code hosting, we can still build lots of cool tools and services around GNOME with it. If you want to help out get in touch, or get in #gnome-bzr.
A while ago I opened a bug asking to make it easier to use bzr-mirror.gnome.org with JHBuild. I proposed a patch which still needed some love, but wasn’t really sure how to finish it. It added a flag so you can say, “if there is a mirror of this for {bzr,git} users, use it”. Recently, thanks to zeenix pestering, I finished it. Of course he quickly identified some issues, which led to changes to the JHBuild code for svn, git and bzr. Among other things, SVN finally got tag support, and has a more consistent decision making path. And JHBuild-controlled-Git can handle branches a lot nicer now.
We really need to start cleaning the modulesets – one of the biggest problems we had is that the properties are getting misused. “../branches/foobar” is not a module, its part of a path! This is the route to pain, misery and suffering! As I find time I hope to clean this up, but for now the JHBuild mirror seems to be working.
To start using it, just set mirror_policy to “bzr” or “git” in your .jhbuildrc. You probably want a clean slate for this – it won’t doing anything clever in terms of taking over existing SVN checkouts. Another option is
module_mirror_policy = {
"conduit": "bzr",
"foobar": "git,
}
I hope to get JHBuild to automate git-svn a little here too (and automatically git-svn init) where appropriate.
The more I think about it the more I don’t want to pick a single DVCS for GNOME. It should be up to whoever is doing the work to use whatever tools they want. Unfortunately having each module choose its own hosting format has its own problems – do i need to check out gnome-super-cool from bzr.gnome.org or darcs.gnome.org? What if maintainer A likes cvs and maintainer B likes Git.
<snipped out the bit where i ramble about all the different options people have already suggested. me rambling FTYawn>
There is another approach. The Git protocol is quite easy. The Git pack container format is easy. The basic Git objects are easy. Who says i have to store Git packs in Git? As long as the client Git can grab packs and push packs it is happy. All other operations are local.
So lets take bzr-playground and run something that provides git:// and git+ssh:// access to the bazaar repositories. Push and pull. We’ll still have a central point from which we can view and checkout a GNOME module and the infra work can focus on a single platform. But the choice of tool i use to do my work is (partially at least) back down to me.
I am currently able to read and write the pack container format as well as speak a decent amount of the git-upload-pack and git-receive-pack protocols. It won’t be the first time i’ve serialized or deserialized git objects, so that won’t take very long. Then its just a case of storing things in Bazaar and maintaining a cache of sha1 to bazaar id. Sure, i’m trivializing here, but i am confident that this is doable.
I’m linking to the code I have so far (its an extension of bzr-git) as a gesture that this isnt total vaporware, but it’s not really anything you can try yet.
lp:~johncarr/bzr-git/git-serve
At this point im mainly interested in collecting +1’s and -1’s on the basic concept.
A few days ago I ran into the old shooting yourself in the foot with a programming language jokes. And then again a day later, it appeared in #vala. At some point today or yesterday I had a mishap with git history editing and have, umm, shot myself in the foot.
In your hands you hold a powerful sniper rifle. Those familiar with it consider it the most impressive and technologically advanced sniper rifle in the world. It is the quickest way to shoot, with bullets travelling at up to Mach 3. Multiple enemies are dead before a single shot is heard.
Impressed at your choice of sniper rifle, you reach to turn off the safety and realise that it doesn’t have one. You reach for the trigger, only to find it is not where you normally expect to find a trigger.
After seeking advice, you are advised to read about the internals of the sniper rifle (its manufacturers say that understanding how the sniper rifle is built is the only way to get the most out of a sniper rifle) you are ready. You start to shoot enemies and find yourself somewhat joyful at the amount of power you are wielding. You feel in control. You feel liberated. Pow pow pow. How did I get anything done before I had this beast?
All your friends, feeling left behind, get one too.
At some point you look down and you realise you shot your foot, a large chunk of it is now missing. Oh well, the pieces are still around if you look hard enough. Here’s a sewing kit.
Luckily I only lost 2 files, which were pretty much unchanged from master. The rest I think I can still get to just by splitting surviving commits. And just when I thought I was about to level up my git abilities too.
(Disclaimer: This is not a cry for help, nor is it a call for flaming, just an unfunny “OMG I SHOT MYSELF IN THE FOOT”).
Federico notes of a change that every single git-mirror user needs to make to every one of their clones to have its tags stay up to date properly. So, dear lazyweb, my question is simply this: How can I (as git-mirror guy) make this annoying git-foo go away? I hate stupid crazy repetitive manual crap that every one of my users has to put up with !
You can see how the mirrors are currently created and updated in the vcs-mirror repository. To share in my vodka and whisky spoils for setting up git-mirror (which, despite idle threats to the contrary, i’m still waiting for) your solution should not disturb existing clones….
(And yes, that is a hg script you see).
Got up early for some healthy debate on the differences between Bazaar and Git at the DVCS Bof. Maybe the slot was changed when I wasn’t looking, but it turned into a “introduction to Git and Gitorious” presentation, with a packed audience. For a session meant to focus on DVCS in general, and how GNOME can move from SVN to $DVCS, it was a bit of a shame. BUT THEN…
There was a second smaller talk on DVCS that was slightly more productive. Neither side has managed to provide an action plan so far. When the Bazaar and the Git advocates can come to GNOME and say “we have a plan, this is how we are migrating and this is how we are going to fix all the systems that depend on GNOME”.. then we can talk. This whole issue needs some JFDI – we can’t cry/shout until our DVCS is picked, and then expect the sysadmins to take care of it.
On a lighter note, got some swag. Quite happy with the laptop bag, and the T-shirt is quite nice. Doesn’t match the codethink t-shirts though 
Now back to cleaning up the Git code so Rob doesn’t harm me.
Always, always, always remember to
git-rebase --continue
Or strange confusing things happen, and if you don’t have experts on hand… FAIL.
(Needless to say, the silly little typo I was trying to rebase away made it into public history after all. Poo.)
zeenix decided to quote me in a recent blog post. My remark was meant to be a light hearted jibe at our obsession with going over and over the same points but never getting anywhere. I failed, but it looks even worse out of context. So lets try this again.
We have ALL heard how Bazaar is so slow you might actually die of old age before you finish checking out your module, and that Git is so hard and voodoo ridden that you will erase your project from history and cause the universe to collapse if you use the wrong incantation.
Both of these arguments are nothing new. They are both very tired, and of questionable correctness in recent versions of both tools. Thats why I didn’t want to hear about them *again*. That doesn’t mean that they aren’t valid concerns, just that covering them again didn’t seem constructive.
As it happens, zeenix posted about how Git is fast. Now some interesting debate is happening over in the comments of that entry, so maybe my poor sense of humour did some good. Note that I never bothered to try and say Bazaar wasn’t slower because i thought it a waste of time and a good way to get flamed, but the people are now saying “hey, Bazaar is actually doing OK”. Yay.
In closing: people, please don’t get upset, i’d never waste my vodka over something like DVCS-wars! Now if this was vim vs emacs…
Bad Behavior has blocked 75 access attempts in the last 7 days.