Design fs.*, db.*, env.* and git.* public APIs about js-git

[juliangruber]

Re db: What about iterators over keys?

• db.each(fn) // iterate over everything
• db.each('foo/bar', fn) // iterate over everything in foo/bar
• db.each({ start : 'a', end : 'z' }, fn) // iterate over a range

Or is adding a strict sorting of keys difficult with the underlying implementation?

Re fs: Could fs.writefile have an append mode?

[chrisdickinson]

some thoughts:

git.hashObject(object) should probably accept a Buffer or TypedArray instance. Strings can be lossy with utf8 encoding ): We could make the api something like so:

var obj = git.objects.commit('author', 'message')

git.save(obj, function(err, oid) {

})

fs.rmfile might be best as fs.unlink for parity with node's fs module.

git.updateIndex might be better as git.index.(get|set|remove).

[chrisdickinson]

@juliangruber We'll probably need a db.keys(callback) that returns all keys for gc'ing, but other than that there should be relatively few operations that require fine-grained control over key iteration.

Basically, the less we need from db, the better -- that way it can easily be represented by localStorage, indexeddb, js object / json, fs, etc.

[chrisdickinson]

that actually brings up an interesting implication: gc'ing in this approach means that we need to get all of the refs from all of the repos (represented by uuids) and iterate keys to find the ones that aren't reachable, assuming object ids (hashes) aren't prefixed with the uuid (which would be nice for storage size reasons).

[creationix]

Yep, since all the repos are merged, gc can only be done on a whole-system basis.

[creationix]

I made a quick fs wrapper around requestFileSystem. (only works in chrome). I think most the semantics are sane. There are still parts to work out around move and copy commands. https://github.com/creationix/js-git/blob/master/demo/app.js#L47-L155

[chrisdickinson]

@creationix awesome work! that would be great as a standalone package on npm!

[mgarciaisaia]

If all objects will be stored in the DB with their hash as the key, wouldn't it be wrong to ask for the key value when storing? Not only it can be calculated by the DB,it HAS TO, for preventing a corrupted key/value pair to be stored.

[creationix]

The idea is that this common db interface not include hash logic in every
implementation. Then a higher got layer can do it once and share the code
among all the db implementations. Also I may want to store refs and tags
in the db which aren't keyed by their content hash.
On May 15, 2013 11:04 PM, "Matias Garcia Isaia" [email protected]
wrote:

If all objects will be stored in the DB with their hash as the key,
wouldn't it be wrong to ask for the key value when storing? Not only it can
be calculated by the DB,it HAS TO, for preventing a corrupted key/value
pair to be stored.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/7#issuecomment-17983588
.

[creationix]

So @mgarciaisaia ended up being right about the hash being inside the db interface as seen at https://github.com/creationix/js-git/blob/master/specs/git-db.md#savesource---continuablehash. I should probably close this issue since most these things are now written out in the specs folder.