Changes between Version 23 and Version 24 of GitObjections

Show
Ignore:
Timestamp:
01/30/10 01:55:14 (4 years ago)
Author:
cotto
Comment:

Mark most objections as addressed. Feel free to disagree.

Legend:

Unmodified
Added
Removed
Modified
  • GitObjections

    v23 v24  
    44   * Answer 1.1: http://trac-hacks.org/wiki/GitPlugin 
    55 
    6 2. Objection: Demonstrate that git actually is better at resolving the merging conflicts we hit in real usage. 
     62. Objection: ~~Demonstrate that git actually is better at resolving the merging conflicts we hit in real usage.~~ 
    77   * Answer 2.1: I know that specific examples would be great here, but does anyone actually doubt that merging is less painful in git? 
    88   * 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. 
    99 
    10 3. Objection: Source code browsing tools. (including revision browsing) 
     103. Objection: ~~Source code browsing tools. (including revision browsing)~~ 
    1111   * 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/ 
    1212   * Answer 3.2: cgit - written in C, faster/less resource-heavy http://hjemli.net/git/cgit/ 
    1313 
    14 4. Objection: Down-time and retraining time for developers. 
     144. Objection: ~~Down-time and retraining time for developers.~~ 
    1515   * Answer 4.1: Migration will take time -- no answer to that. 
    1616   * 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. 
     
    2121       * Committers offering to conduct training: DukeLeto (Lecturer at Git Ninja University) 
    2222 
    23 5. Objection: Safety of the core source (limiting the damage possible accidentally or by new committers) 
     235. ~~Objection: Safety of the core source (limiting the damage possible accidentally or by new committers)~~ 
    2424   * Claim 5.1: (with git it's possible to make changes that destroy the history of the repository) 
    2525     * 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). 
     
    3737   * Answer 6.2: It is also reasonably trivial to have a subversion mirror of the Parrot git master branch. 
    3838 
    39 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." 
     397. 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."~~ 
    4040   * Answer 7.1 : HLL's should be tied to a released version of Parrot. 
    4141 
    4242This 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 
    4343 
    44 8. Objection: Windows support for git is not first-class. 
     448. Objection: ~~Windows support for git is not first-class.~~ 
    4545 
    4646I have heard this objection, but don't have a pointer to either a validation or a refutation. lazyweb, work your magic. --coke