Nick Hengeveld [off-list ref] writes:
About that "-r" arg - seems like it should be something else as -r is
used elsewhere in git to enable recursion. "-c" was my first thought,
but that's used to fetch commit objects.
Well, I'd suggest just to hardcode a reasonable value to be a
good net citizen, and not make it configurable. Four, perhaps?
OTOH, we may want to have an option to disable parallel from the
command line (I think -r 1 would mean that with yours).
If we really want to have the number of parallel configurable,
and -r implies recursive as you say, maybe '-j' to mimic
parallel make?
On Thu, Oct 06, 2005 at 05:51:53PM -0700, Junio C Hamano wrote:
Well, I'd suggest just to hardcode a reasonable value to be a
good net citizen, and not make it configurable. Four, perhaps?
OTOH, we may want to have an option to disable parallel from the
command line (I think -r 1 would mean that with yours).
I'd prefer to keep it configurable - for our purposes we'll be hitting
a single server from several clients and will probably want to limit
concurrent connections to something like two per client, but when doing
a fetch from a big server farm more connections would make sense.
If we really want to have the number of parallel configurable,
and -r implies recursive as you say, maybe '-j' to mimic
parallel make?
Not that I'm a huge fan of using environment variables, but it might make
sense to use one here. That would allow the setting to work whether
git-http-fetch is run directly or via git-fetch. GIT_HTTP_MAX_REQUESTS?
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.