I managed to talk my company into git as well - although our route is different: We literally had no (official, my projects always ended up using a private repository of some sorts) source control. At all.
So, after fighting the battle for far too long I'm now rolling out git/gitorious right now, with lots of early adopters using that already, on my (properly backed up..) test machine.
The biggest issue that I've seen so far are mostly general "I just don't get scm" things (no commit message or a useless one. Working around rules by just entering space if I try to prohibit this).
The only git specific issue that come up is that the people don't understand that each user's clone/working copy is a separate branch of the origin already. If 2 guys clone from the "server", you now have 2 branches of origin/master. pull by default merges remote and local branch, which leads to a huuuuuge number of completely useless merge commands in the histories of some projects. That makes the history far less useful in my book and all visualizers now show you a large numbers of branches that you don't care about.
You can work around that by educating users to, for example, using git pull --rebase - but that is a concept that needs quite some understanding first.
Apart from the thing above the introduction seems to work fine so far and people with different background (VSS.., cvs/svn mostly) are using it without (real, major) problems.
And I'm glad that we finally will have an official scm server sometime this month, after only ~5 years of nagging. Ah, it's the small things that make me happy these days...
So, after fighting the battle for far too long I'm now rolling out git/gitorious right now, with lots of early adopters using that already, on my (properly backed up..) test machine.
The biggest issue that I've seen so far are mostly general "I just don't get scm" things (no commit message or a useless one. Working around rules by just entering space if I try to prohibit this).
The only git specific issue that come up is that the people don't understand that each user's clone/working copy is a separate branch of the origin already. If 2 guys clone from the "server", you now have 2 branches of origin/master. pull by default merges remote and local branch, which leads to a huuuuuge number of completely useless merge commands in the histories of some projects. That makes the history far less useful in my book and all visualizers now show you a large numbers of branches that you don't care about.
You can work around that by educating users to, for example, using git pull --rebase - but that is a concept that needs quite some understanding first.
Apart from the thing above the introduction seems to work fine so far and people with different background (VSS.., cvs/svn mostly) are using it without (real, major) problems.
And I'm glad that we finally will have an official scm server sometime this month, after only ~5 years of nagging. Ah, it's the small things that make me happy these days...