Moving to Git


  • Familiar to most devs
  • 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.
  • Painless branching
    • branches can be created and destroyed at will, including remote branches (unless configured otherwise)
    • Clones of the repo give the full history, including all branches
  • Ability to rewrite history/commits before they land in trunk (rebase)
  • Tool support
    • Wide support in IDEs
    • Trac
    • Jenkins
    • many other tools one might have in their dev toolbox
  • Repository can be distributed as Git bundles or tarballs
  • Small repository size (currently ~65MB with all branches)
  • 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.
  • 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
  • Multiple supported web front-ends (gitweb, cgit). For Monotone there's just the abandoned ViewMTN.
  • Powerful hook support. Hooks can be in any language.
  • 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:
    • explicitly specify the files to be added to the commit (e.g. git commit apps/i2ptunnel router/java/src/net/i2p); or
    • stage the desired files with git add, then commit; or
    • commit all changed files with git commit -a
  • Ability to review changes before pulls


  • 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.
  • Pulls & clones do not resume. Broken tunnels will require the pull to be started from the very beginning. This is primarily a problem if one tries to clone the repository within I2P but it can be mitigated with snapshots or git bundles.
  • 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.
  • Existing I2P developer toolchains are set up for Monotone usage.

The 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.

IM(kytv's)HO, the rest of the items are not important at all.

  • Lost revision ID metadata: Meh. We'd have Monotone to fall back on when/if needed.
  • TZ leakage: We could have a ant target that sets up various I2P-specific git configs 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.

Other notes

  • Systems other than Windows and Linux are limited to Monotone v0.48 or older.
  • Some systems cannot easily compile Monotone anymore. Moving from Monotone may eventually be a case of "we need to" instead of "we should". We're not there yet but we do need to think about it.
  • Signed commits are possible but they'd have to be either manually verified or a hook would have to be written if signed commits are necessary. Linus Torvalds argues that signing each commit is absurd.
  • 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
    git config checkout
    git config alias ci commit
    git config alias.rb rebase
    git config status
Last modified 4 years ago Last modified on Jul 5, 2017 1:05:40 AM