This might need #395 before it works correctly.

During my testing it seemed to work
On Feb 10, 2015 12:05 PM, "John Haley" notifications@github.com wrote:

This might need #395 #395
before it works correctly.

—
Reply to this email directly or view it on GitHub
#325 (comment).

It should break on windows since msbuild will init int values to not-zero. Which I think would cancel the transfer as soon as it gets that value back. #388 is also fixing that specific value but for a more robust fix #395 will have to be resolved.

Rebased in latest.

Interesting, any idea why the HTTP clone test skipped?

@maxkorp there is a bug/issue in libgit2 about cert checks and http->https redirection. our http test is not really http so we need to rename/fix.

Gotcha! Yeah, described here: 25d7d88

How long is the fetch taking? That callback is going to get called after a minimum of half a second. If the fetch is taking less time than that, it won't get called.

https://github.com/libgit2/libgit2/blob/a7fa970f8b216b79a5d237a9d87ac88e2371ae46/src/pack-objects.c#L62

https://github.com/libgit2/libgit2/blob/a7fa970f8b216b79a5d237a9d87ac88e2371ae46/src/pack-objects.c#L245

Additionally, if you add a new remote that's pointed to the same url then libgit2 will know it downloaded the packs already and won't go out to download them again. I'm going to get nodegit/test2 up and have it much further ahead (commit wise) than nodegit/test so that we can really get some download data going for the test to work.

Regarding statelessness, would it make sense to then delete that remote and do a git GC afterwards, to make sure the packfiles get nuked?

Edit: Or you know, that could be in an existing commit that github just wasn't showing me >.<