Add Blob::size()

[ksqsf]

I hope this is trivial enough. :-)

[ehuss]

Is there a reason to choose usize instead of git_off_t? I think (although unlikely) this will silently truncate on 32-bit systems.

[ksqsf]

Indeed, it should be a 64-bit integer type, but I'm quite confused which type should be used here. git2 doesn't seem to return any value of a "raw" type (like git_off_t) so I picked u64, as a size should be an unsigned integer.

[alexcrichton]

Hm so actually, I might disagree with the usize -> u64 transition because I think a Blob is guaranteed to be in-memory, which guarantees that the size fits in usize. I'm not sure if git can handle >4GB blobs maybe?

[alexcrichton]

(or maybe this is an API bug in libgit2 by exposing the ability to load any blob in-memory)

[ksqsf]

If I understand the code of libgit2 correctly, libgit2 will read the data (ie. the contents of a blob) into memory, so this indeed looks like a flaw. However, since git by design supports large blobs, returning u64 here should be safe and correct, and libgit2 maintainers might improve this later.

[alexcrichton]

We already have an API that looks like pub fn content(&self) -> &[u8] so even if libgit2 is changed that would require a breaking change here, so I think it's fine to leave this as usize for now

[ksqsf]

Fair enough. I've reverted the last commit.

[alexcrichton]

@ehuss, to confirm, are you ok with the usize change?

[ehuss]

Oh, yea, seems fine to me!