Objections to using Git as a VCS, per discussion at  http://irclog.perlgeek.de/parrot/2009-09-17#i_1510436 .

1. Objection: Integration with trac.

• Answer 1.1:  http://trac-hacks.org/wiki/GitPlugin

2. Objection: Demonstrate that git actually is better at resolving the merging conflicts we hit in real usage.

• Answer 2.1: I know that specific examples would be great here, but does anyone actually doubt that merging is less painful in git?

3. Objection: Source code browsing tools. (including revision browsing)

• Answer 3.1: gitweb - has more fancy features, like avatars and such
• Answer 3.2: cgit - faster/less resource-heavy, but written in C

4. Objection: Down-time and retraining time for developers.

• Answer 4.1: Migration will take time -- no answer to that.
• Answer 4.2: Developers can retrain with git-svn prior to migration. If anything, using Git alone is *easier* than with git-svn.
• Answer 4.3: Git supports a workflow very much like the existing SVN workflow. It's not the ideal Git workflow, but it's similar enough that retraining will be short.

5. Objection: Safety of the core source (limiting the damage possible accidentally or by new committers)

• Claim: (with git it's possible to make changes that destroy the history of the repository)
• Answer 5.1: Have a server side post-commit hook that disallows non-fast-forward updates. That negates any possibility of a newbie messing up the master Parrot git repo.
• Answer 5.2: Also, the history is not destroyed, just altered. The history is still there and can easily be fixed from another Parrot git repo.

6. Objection: Upstream projects depend on getting Parrot from svn.

• Answer 6.1: Ensure that those projects are given sufficient advance notice of any VCS switch. This includes HLLs and derivative projects such as mod_parrot. A list of such projects should be maintained.
• Answer 6.2: It is also reasonably trivial to have a subversion mirror of the Parrot git master branch.