g. Anyone having local branches which are based off of commits in the old git repository will have to rebase those branches onto the correct new hashes of the old commits (this actually is quite easy to do).
How do you go about that? Manually rebasing every branch, or is it easier? (Guess I'll get some experience on that too when you rebuild the repo next time. ;)
Even if it's simple to rebase, I think it'd be best to avoid steps f-h as much as possible. If nothing else, it's inconvenient (and confusing) to have to keep several old repositories around just to be able to follow old mail threads.
My experience with git so far:
It's a very good tool to work locally with. In the long run this is clearly the way to go to organize one's own hacking, imo. Even if we don't go for git on the server for some time yet, I think I'll be using it for myself.
It shows quickly that it isn't a mature system yet, though. As some kind of measurement, I can mention the time until I found it necessary to pull home the source to fix the flaws that started to annoy me: For git it was two days, which I think is a record. (Btw, I've got home built Ubuntu Hardy packages for 1.5.6.4 if anyone's interested.)
I don't agree very much with the intended collaboration model, though. Apparently there should be no central repository, only developers that pulls each other's changes in some ad-hoc way. We're supposed to appoint a maintainer who everyone else has to ask to manually pull in their patches. This has "so many advantages" over letting developers just update a shared repository by themselves. Well..
But there's no need to import this model, of course; git can work just fine with a shared repository too. I wouldn't like to see the plethora of branches and merges on the server, though. A nice linear sequence of commits on each version branch keeps things simple. We've been working that way for years now and I haven't seen any real reason to change that. But that shouldn't be a big problem to accomplish just by dictating policy, I guess.
Zino has good points that svn fits better on the server: It's more mature, it's closer to cvs so that the server tools around it don't need much change, and it's afterall built with that sharing model in mind.
Maybe a good way to accomplish both ends is to use the bidirectional git-svn bridge? Afaict it's made for the case when the primary repo is in svn. It advices against doing git-style heavily branched development, which is good on the server side (see above). And using svn for storage allows properties, which git lacks. I will play around a bit with git-svn.