Changes between Initial Version and Version 1 of Git

Mar 26, 2014 5:26:18 PM (7 years ago)

Thoughts about Git


  • Git

    v1 v1  
     1= Moving to Git =
     2== Pros ==
     4* Familiar to most devs
     5* Though some would disagree, it's easy to use and learn. At least the basics are easy to grasp. If you know Monotone, using Git won't be a problem.
     6* '''Painless''' branching
     7   * branches can be created and destroyed at will, including remote branches (unless configured otherwise)
     8   * Clones of the repo give the full history, including all branches
     9* Ability to rewrite history/commits before they land in trunk (`rebase`)
     10* Tool support
     11  * Wide support in IDEs
     12  * Trac
     13  * Jenkins
     14  * many other tools one might have in their dev toolbox
     15* Repository can be distributed as ''Git bundles'' or tarballs
     16* Small repository size (currently ~65MB with all branches)
     17* Repositories can be hosted via `HTTP`, `HTTPS` `SSH`, `rsync`, or the native `git` protocol making it easy for someone to create a "one off" repository.
     18* Push rights not needed to contribute. One could quickly set up a repo on his/her eepsite for changes to be pulled by another dev with `git pull http://someeepsite.i2p/i2p.git master`
     19* Multiple supported web front-ends (gitweb, cgit). For Monotone there's just the abandoned ViewMTN.
     20* Powerful hook support. Hooks can be in any language.
     21* By default, no changed files are staged for commit. This would prevent n00b mistakes committed when doing `mtn ci -kn00b@mail.i2p`. To commit changes you '''must''':
     22 * explicitly specify the files to be added to the commit (e.g. `git commit apps/i2ptunnel router/java/src/net/i2p`); or
     23 * stage the desired files with `git add`, then commit; or
     24 * commit all changed files with `git commit -a`
     25* Ability to review changes before pulls
     27== Cons ==
     29* Some of the historical metadata will be lost. Example: "Fixed in revision `2aa15805ec56c38779cd71ce576881bd03edf2e5`" will be invalid because the MTN revision IDs won't carry over.
     30* Pulls & clones do not resume. Broken tunnels will require the pull to be
     31  started from the very beginning. This is primarily a problem if one tries to
     32  clone the repository within I2P but it can be mitigated with snapshots or
     33  ''git bundles''.
     34* Commits are not stored in UTC. Users that don't want to work in UTC can set up an alias like `alias git='TZ=UTC' git`.
     36The lack of resume is the only important ''con'', but as said above, this could be mitigated by distributing `bundles` or snapshots, possibly for each new release via torrent, hosted on an eepsite, etc, or one could do an initial pull via Github.
     38IMHO, the rest of the items are not important at all.
     40* Lost revision ID metadata:  Meh. We'd have Monotone to fall back on when/if needed.
     41* `TZ` leakage: We could have a ant target that sets up various I2P-specific `git config`s and could set up hooks for users, such as a `pre-commit` hook to warn about the TZ and give advice as to how to ''fix'' it.
     43== Other notes ==
     45* Systems other than Windows and Linux are limited to Monotone v0.48 or older.
     46* Some systems cannot easily compile Monotone anymore. Moving from Monotone may
     47  eventually be a case of "we need to" instead of "we should". We're not there
     48  yet but we '''do''' need to think about it.
     49* Signed commits are possible but they'd have to be either manually verified or a
     50  hook would have to be written if signed commits are necessary. Linus Torvalds
     51  argues that [ signing each commit is absurd].
     52* Monotone can use the git commands like `commit` or `checkout` but Monotone also has shortcuts like `ci` or `co`. Out of the box, Git does not. Aliases can be easily added, however, such as   
     54git config checkout
     55git config alias ci commit
     56git config alias.rb rebase
     57git config status