nip

nip is a git remote helper that'll put your repo's objects on IPFS - i.e. Nowhere In Particular.

Installation

Like with most Rust packages, the easiest way to install will be using Cargo:

$ cargo install nip

Usage

Important: Before you try to use nip please make sure that your local IPFS instance is running on its standard port.

Pushing an existing repo to a nip remote for the first time

$ git remote add nip nip::new-ipfs # Use a magic placeholder URL representing a new IPFS repo
$ git push --all nip # Push all refs to a brand new repo

Cloning a repo from nip

$ git clone nip::/ipfs/QmZq47khma5nP7DjHUPoERhKnfNUPqkr5pVwmS8A6TQSeN some_repo

Repo administration with nipctl (WIP)

nip comes with nipctl - a utility for nip repo administration. As for today Its functionality is very minimal (printing of objects and indices), but some of the planned features include:

• Garbage collection - for removing all objects not associated with any refs items
• Managing git push notification settings - Depends on https://github.com/drozdziak1/nip/issues/7

How does it all work?

See FAQ.md for a tour of underlying nip functionality.

Development

If you'd like to hack on nip, the dev_bootstrap.sh script is where you should start. It symlinks nipctl and git-remote-nip as nipdevctl and git-remote-nipdev in ~/.cargo/bin, respectively. As a result, git will pick git-remote-nipdev for every remote that has a nipdev::<hash_or_mode> address instead of git-remote-nip, which enables painless testing during developing.

Limitations

• Running times - nip will only work as fast as IPFS lets it.
• Repo pinning and git push notifications - people interested in keeping track of remote repo's progress have no way of knowing about pushes made to it. See this issue for progress on the solution.
• Disk space - by design local git objects need to have IPFS counterparts which are kept in your local IPFS node's data store. In practice this means that every local object pushed to a nip repo needs to be stored on your disk again in a form that IPFS understands. However, nip guarantees object deduplication for all repos you use with it, which means a given git object is stored on IPFS only once, no matter the repo it comes from.
• Object size - nip doesn't know yet how to stream objects into/out of the local repository and will attempt to load them into RAM, this increases the memory footprint substantially for repos that posess large objects. Tracked here.