getObject

[billiegoose]

So as nice as the high-level API is, there are times where you want to get your hands dirty, and do specialized batch operations without wasting time doing a full "git.checkout".

To that end, I'm thinking about adding an API function that would provide some of the benefits of using the GitObjectManager directly.

await git.getObject({
  oid: string,
  format: string
})

values for format:

• 'raw' - returns raw deflate-compressed file. Useful for manually unpacking objects from packfiles or efficiently shuffling around loose objects - whenever you don't care about the contents you can save time by not unzipping them
• 'plain' - returns deflated object as Buffer. Useful for calculating SHA object ids
• 'content' - returns object content, minus the git header
• 'parsed' - default. parse the object and return a JavaScript object using one of the schemas (CommitDescription, BlobDescription, TreeDescription, TagDescription)

Example usage:

let sha = await git.resolveRef({fs, dir, ref: 'mybranch'})
let commit = await git.getObject({fs, dir, ref: sha})
let tree = await git.getObject({fs, dir, ref: commit.tree})
for (let file of tree.entries) {
  if (file.path === 'package.json') {
    let blob = await git.getObject({fs, dir, ref: file.oid})
    console.log(blob.toString('utf8'))
  }
}

[billiegoose]

@mojavelinux thoughts?

[mojavelinux]

I like the fact that you're using the same function to get each object in succession since that reflects how git actually works.

I would think you'd need to specify the type/format for the last call in your example:

let blob = await git.getObject({fs, dir, ref: file.oid, type: 'content'})

right? otherwise, I'd expect to get a BlobDescription based on your proposal.

I'm worried we're overloading the meaning of "type" (see https://git-scm.com/docs/git-cat-file). Type is already used for the object type (tree, blob, etc). Perhaps format instead?

[billiegoose]

otherwise, I'd expect to get a BlobDescription based on your proposal.

True! It would probably be blob.data.toString() or something.

Perhaps format instead?

I thought I did call it format... no worries! I agree that 'type' already has a meaning. I definitely won't call it type. :)

[mojavelinux]

👍

[billiegoose]

I changed the names for more consistency / descriptiveness. Instead of getObject it is readObject (because presumably we will add a writeObject at some point) and instead of 'raw' and 'plain' I called them 'deflated' and 'wrapped'. Soon as the CI tests pass it should be published!

https://isomorphic-git.github.io/docs/readObject.html