Re: What's the best way to make my company migrate to Git?

[Daniele Segato <daniele.bilug@gmail.com>]

On Sun, May 23, 2010 at 4:52 PM, Andrew Sayers
<andrew-git@pileofstuff.org> wrote:
> I agree that a lead developer moving a team from graphical SVN is a
> different problem.  I don't think git-gui does SVN, I couldn't work out
> how to make TortioseGit work with SVN, and I doubt EGit will like SVN
> very much.

EGit do not work with git-svn, it probably work just fine with "pure" git tough.
I've seen TortoiseGit, it work very well but I found it somewhat more
difficult then the command line:
probably because I don't know where to find the command i daily use on git.
I extensively use git grep and probably there isn't anything like it
in TortoiseGit.

> You're also right that git-svn has limitations with merging and
> rebasing.  Specifically, don't use them unless you know what you're
> doing - see `man git-svn` for more.  Git-svn is also less
> newbie-friendly than either git or svn on its own.

Yes, that's why I'd like to skip git-svn and go directly with git,
unless I know the people I'm teaching to can
handle it.

> Having said that, I'd still recommend you try moving a few developers to
> git during the lifetime of your current project.  In my experience,
> those developers most willing to try something new in the middle of a
> project are also the ones that want to get hacking right away on a new
> project.  Getting even one developer to start migrating now will be good
> practice for you, and will double the number of eyeballs looking at git
> issues later on.

Yeah, there is one developer tired of Subversion that asked me to
teach him git(-svn).
He's not in my team but I think it's a starting point :)

> Slowing down for less than a week is a very ambitious target - I think
> we had about 2 weeks of noticeably reduced productivity, even when I'd
> done a lot of work to spread the pain over several months.  Starting git
> with a new project might reduce that time a bit - for example, there's
> no chance of uncommitted work in an SVN checkout failing to make the
> switch.  But it can be more expensive in the long-run, because you have
> to make all of your architectural decisions based on what you can
> explain to SVN users on day one - for example, my team took about 2-3
> weeks to understand how a commit is different from a push, and why they
> should care.  But because they understood before we made the big leap,
> we were able decentralise our workflow as much as we needed.


Probably it will be a svn-like architecture from the beginning, I'll
not dare to move it any
further until I know that developers are ready to handle it properly :)
I'm not sure myself I can manage a workflow different from subversion
(1 main server and N developers
pushing to it) because I never did anything different.


> If you do go via git-svn, I'd recommend you read `man git-rerere` and
> set the config option "rerere.enabled" to "true" for all users.  I
> needed to blow away a few messy merges to fix rookie mistakes, and
> `git-rerere` would have made a painful experience much easier.

I did not know about this.. That's really interesting, I just enabled
it in my local repo.
Thanks for the hint!

> Even if you go straight into git, you might think about finding/writing
> hooks to synchronise an SVN repository and a git repository.  There will
> probably be a few people you can't switch right away - e.g. a sysadmin
> that would need months to rewrite all his scripts, or a designer that
> doesn't want to learn a different tool just for your team.  Providing a
> semi-functional legacy interface for those people will let you raise the
> pressure on them more gradually.

Sysadmins shouldn't be a problem, we don't have sysadmins here and if
the custumer
require us to use his own versioning system we can't push them to git,
so I think that wouldn't be
a proble for us. But that's a good point.

> I forgot to mention education in my previous post, which was actually
> one of the biggest problems during the move.  I was surprised how
> everyone had such different learning styles - some wanted to learn the
> theory then be left alone, some wanted to be told each solution at the
> moment they faced the problem, some wanted to learn by watching how I
> worked, etc.  The only real pattern seems to be that the busier people
> are, the more they like to feel they're pulling information out of you,
> and the less receptive they are when you push information at them.  I
> muddled through by trying to give everyone more of whatever they each
> reacted best to.

Thanks, I'll keep that in mind when I'll face the big switch.


> Because my team needed time to unlearn a lot of these SVN issues, I
> didn't try to push much deep git tech at them early on.  A few months
> into the move though, it's starting to seem like a better idea.  One of
> my team-mates got me to start reading "Version Control with Git"
> (http://oreilly.com/catalog/9780596520137) - from what I've seen so far,
> I'd definitely recommend it to people that like book-learning and are
> ready to learn git without bringing their old SVN baggage.  On the other
> hand, you can cobble the same information together from various online
> sources if you prefer (http://book.git-scm.com/ is a personal favourite).


Thanks about the book suggestion, I'll give them both a try!

Regards,
Daniele Segato