|Version 22 (modified by jimmy, 7 years ago)|
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?
- Answer 2:2: Several recent merges (pluggable_runcore, kill_pic, kill_jit, possibly others) using the svn client have been thwarted by server-side errors. In these cases bacek has been able to merge using git-svn.
3. Objection: Source code browsing tools. (including revision browsing)
- Answer 3.1: gitweb - written in Perl, easy to customize,prettier, many fancy features, like avatars. Example of an older (git 1.5.x) gitweb instance: http://leto.net/gitweb/
- Answer 3.2: cgit - written in C, faster/less resource-heavy http://hjemli.net/git/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. Developers can also fork the mirror of Parrot on github http://github.com/leto/parrot and practice their git workflow.
- 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. (See also GitCookbook-Pm.)
- Question 4.4: How many existing active committers
and developersmight need retraining? I suspect the number is small.
- Committers requesting training if we proceed: ...
- Committers offering to conduct training: DukeLeto (Lecturer at Git Ninja University)
5. Objection: Safety of the core source (limiting the damage possible accidentally or by new committers)
- Claim 5.1: (with git it's possible to make changes that destroy the history of the repository)
- Counter-claim 5.1.1: This seems very unlikely to happen, and detecting/mitigating a problem is not at all difficult (see Answers 5.2 through 5.4 below).
- Answer 5.2: 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.3: Also, the history is not destroyed, just altered. The history is still there and can easily be fixed from another Parrot git repo.
- Answer 5.4: Every single git work tree of Parrot is a backup of the entire source code history. Currently, if the svn repo on parrot.org were to be hit by a meteor, we would be in a bad way. Our code is safer in git.
Upstream projects depend on getting Parrot from svn. (cotto)
- Claim 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.
- Counter-claim 6.1.1: According to Parrot policies, HLLs and other projects should not be dependent on the VCS but should restrict their work to released versions of Parrot. Projects that choose to have a dependency on the master Parrot VCS do so at their own risk.
- This counterclaim is true. HLLs officially shouldn't be depending on Parrot's VCS. If they want to, they can figure something out or copy whatever Rakudo ends up doing. - cotto
As an HLL author, I can't track parrot releases exclusively by release. However, even when I do, I do not track it via svn, but by requiring the user to get their own copy and install it (So my issue is #7, below) --coke
- Answer 6.2: It is also reasonably trivial to have a subversion mirror of the Parrot git master branch.
7. Objection: HLL's that want to be able to say that they require a certain minimum version/revision of Parrot will have a harder time, since git commit SHA1's are not "linear."
- Answer 7.1 : HLL's should be tied to a released version of Parrot.
This may be reasonable for HLL releases, but not for HLL development. That said, a harder time figuring out which versions are OK is fine, as long as it's not impossible. I can even remove the programmatic check and simply warn the user. If we do develop a programmatic solution, this cost can be shared among those HLL implementors that need it. --coke
8. Objection: Windows support for git is not first-class.
I have heard this objection, but don't have a pointer to either a validation or a refutation. lazyweb, work your magic. --coke
- Answer: This used to be true, but the Git team has worked hard on this in the past year.
- Git+Github+Windows for Newbies: http://github.com/guides/using-git-and-github-for-the-windows-for-newbies
- Illustrated Guide to Git on Windows: http://nathanj.github.com/gitguide/tour.html
- msysgit: http://code.google.com/p/msysgit/
- TortoiseGit: http://code.google.com/p/tortoisegit/