Indirect all objects to a traditional IPFS filesystem

[dysbulic]

All objects are stored in their raw form in directories named for their type (.git/commits, /.git/trees, …).

Removing the header allows creating IPFS file structures using the blobs, so the root of the created repo is the contents of the HEAD commit.

An optional .git/vfs/ structure is created which gives access to all the commits as a file system.

IPNS support is added both for pulling and pushing to a key.

A breaking change is the project is referred to as ipfs-shipyard/git-remote-ipfs since IPLD is no longer used.

[dysbulic]

I discovered that since I am storing hundreds of references to the commits in the virtual filesystem (I built the tree for each commit) it makes the reported size of the repo huge.

The 20MiB repo with ~100 commits has a reported size of 5TiB.

While it is not an issue for usage, it does affect pinning services (and maybe filecoin). I had a discussion this morning on Pinata's Slack where their lead tried to convince me IPFS was somehow broken and to submit a bug to go-ipfs.

I need to address this, and while I welcome comments, I would like to delay merging until I can do a refresh of IGiS to accompany this.

[dysbulic]

Ok, so I have rewritten everything in javascript. It is about five times slower, but I decompose the git object into DAG Objects rather than maintaining a table of the entire object database. None of the SHA1 hashes are saved. Commit parents are of the same type as their children. Trees are regular IPFS filesystems.

QmZZsVWQZHC3VF6axjLPEZjbCYjddTXmNs41tkCv6yuB8U

The root of the filesystem is still the checked out branch, and the git information is stored under .git

Surprisingly enough when those structures are fed into NodeGit, it will produce the original SHA1s and object database even with signatures.

I think the Go program this pull request references is dead in the water. I want to use OrbitDB which means javascript.