Add the streaming indexer to the bindings

[carlosmn]

There are a few things that I'm not so sure about, style-wise.

Firstly, the indexer's stats are actually unsigned int in C, but if I try to put that in the struct, I get a warning that it's not CLS complaint, so it it may not work. @nulltoken, do you have any insights into this?

Secondly, I transform the stats into the C# variant after each add, which could be too much work, if the stats are looked up less often. I thought about doing it on demand, but that would mean locking and I worry that it would mean even more work.

Thirdly, is there some extablished convention whereby I can make clear that you shouldn't call Indexer.Hash() before the indexer is done?

[carlosmn]

I've left Add(byte[]) for now until we figure out whether I should just start a new Thread/Task when demultiplexing the input from the remote or we can find a better way of making it work.

[carlosmn]

After much dragging my ass, I've updated this so it reads from a Stream instead of manually appending arrays. I think this is what we were talking about way back when, @nulltoken . Maybe I should change the author date to something more current...

[nulltoken]

Haven't we previously discussed about also making the progress callback based? Unless I'm wrong, current design would require a separate thread to observe the progress.

[nulltoken]

BTW, Travis doesn't like you today 😉

/home/travis/build/libgit2/libgit2sharp/CI-build.msbuild: error : LibGit2Sharp.Tests.IndexerFixture.CanIndexFromAStream: LibGit2Sharp.LibGit2SharpException : An error was raised by libgit2. Category = Invalid (Error).
Failed to open packfile.: Permission denied
/home/travis/build/libgit2/libgit2sharp/CI-build.msbuild: error :   at LibGit2Sharp.Core.Ensure.HandleError (Int32 result) [0x00000] in <filename unknown>:0 
  at LibGit2Sharp.Core.Ensure.ZeroResult (Int32 result) [0x00000] in <filename unknown>:0 
  at LibGit2Sharp.Core.Proxy.git_indexer_append (LibGit2Sharp.Core.Handles.IndexerSafeHandle handle, System.Byte[] data, UIntPtr length, LibGit2Sharp.Core.GitTransferProgress& progress) [0x00000] in <filename unknown>:0 

[carlosmn]

We might have talked about that, yeah. The indexing is really something that happens in the background, but sure, I'll add some callback.

I'm not sure what to make of the travis error. I'll take a look tomorrow.

[nulltoken]

Could you please add some doc explaining how by just using this type, the user will magically be teleported into a wonderful land full of rainbows and unicorns?

[carlosmn]

I'm not sure wtf I was doing earlier, but the indexer has all these fancy parameters I was just skipping over.

I'm now facing adding the progress callback and I notice that RemoteCallbacks has this nice GitDownloadTransferProgressHandler that's private but I would very much like to use. Now, should I make it internal instead of private, or should we do some larger refactoring?

[jamill]

GitDownloadTransferProgressHandler depends on some internal state of RemoteCallbacks (the consumer supplied DownloadTransferProgress delegate to call, if any), so this will require more than just changing the accessibility of the method.

[carlosmn]

Yeah, you're right. I guess I'll have to end up transplanting the logic so it uses local functions.

[carlosmn]

I've brought this back from the dead, the style issues have been addressed and we only actually deal with Streams anymore.

I'm not sure how much explanation there should be for the class; I figured mentioning it's the equivalent to index-pack should be enough for anybody who would want to use it.

[ethomson]

Stream.Read can return negative here on failure - we should break if read <= 0.

[ethomson]

Let's get this out of LibGit2Sharp.Advanced. Instead, let's just put it into LibGit2Sharp... This seems to be in keeping with the trend of making LibGit2Sharp the "core" area and move the "simpler" stuff into Commands...?