Allow push APIs to set packbuilder parallelism

[ethomson]

We want to crank up the parallelism of the packbuilder when we do pushes!

[ethomson]

@nulltoken Do you hate an Options with only one member? Should we move Credentials in there? Should we just hang an int param on the various Pushes?

[ethomson]

Note that @jamill 's name is on this commit he thinks that but @phkelley wrote it? I don't really know; a gold star to both.

[jamill]

I think the Options parameter is the direction we talked about moving in, and then the Credentials and other callbacks would move inside of the Options parameter as well. And then, when more of the progress reporting for push is exposed, these callbacks can live in there as well (and maybe parameters for exposing force pushing, etc).

[nulltoken]

Wow! Thanks to the three of you, then 😉

Just a quick question: How greedy is the auto-detection mechanism? What would be the potential side effects if 0 was the default (eg. when run in IIS, for instance)? What is the possible range of values? When would one to actually "control" the number of threads?

Do you hate an Options with only one member? Should we move Credentials in there?

What @jamill said!

[ethomson]

@nulltoken : One thread per CPU: https://github.com/libgit2/libgit2/blob/development/src/pack-objects.c#L1076

If 0 was the default then we would have a very obscure enforcement on building libgit2 with GIT_THREADS=ON: https://github.com/libgit2/libgit2/blob/development/src/pack-objects.c#L162 . I think that libgit2sharp taking a hard requirement on a threaded libgit2 would be unfortunate, as I often neglect to build libgit2 with threads for simple tests that I know won't need it. But even if we do, then we should have a superior method for blocking users from doing this (as opposed to having libgit2 abort if we ever call push.)

I hesitate to enforce some limit here on the number of threads. The system is a better judge of this that we are.

[nulltoken]

But even if we do, then we should have a superior method for blocking users from doing this (as opposed to having libgit2 abort if we ever call push.)

I'd prefer the defaults to make sense.

How about leveraging git_libgit2_capabilities() (maybe in the NativeMethods static ctor) to detect the threading caps and make PushOptions.PackbuilderParallelism default to either 0 or 1 according to this?

We may even add a check that would throw an explicit message when 0 is used and the lib has been built with GIT_THREADS=OFF.

While we're at it, we may even update Repository.Version to reflect the built-in libgit2 capabilities.

[nulltoken]

How about PackbuilderDegreeOfParallelism?

[ethomson]

I was going to say that we should just go fix libgit2 so that 0 does something sensible. Then I read the function again, and it doesn't test the given argument, it asserts on the existing setting. So, yeah. Let's just make it zero and be done with it. I'll make sure that I'm actually reading this correctly this time.

[ethomson]

Okay, the parallelism default is now 0, and Credentials have moved in to the PushOptions.

[nulltoken]

The default value is 0.

[ethomson]

Indeed. Fixed!

[nulltoken]

@ethomson 🎱