HTTP/1.1 -1 Read error in cache disk data: SuccessContent-Type: text/plain; charset="utf-8" Last-Modified: Sat, 22 Jan 2022 03:49:21 GMT Content-length: 1824 Connection: Close Proxy-Connection: Close X-Cache: HIT from web1.osuosl.org Server: ProxyTrack 0.5 (HTTrack 3.49.2) 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? * Answer 3.2: cgit 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.