When we first developed the "pure" SSH-only Git LFS object transfer
protocol in PR git-lfs#4446, our initial prototype supported only a single SSH
connection, and so in commit 594f8e3
of that PR we updated the NewManifest() function in our "tq" package to
set the maximum number of concurrent transfers to one when the new
SSH adapter was in use.  We also added a comment which states that
"Multiple concurrent transfers are not yet supported".

Later in the same PR we implemented support for multiple concurrent
SSH connections using the ControlMaster option of the ssh(1) command,
and so in commit 9c46a38 we revised
the NewManifest() function to no longer set the maximum number of
concurrent transfers to one when the new SSH adapter was in use.
However, we accidentally left the comment regarding the lack of
support for concurrent transfers in place.

Then in commit b44cbe4 of PR git-lfs#5136
we resolved the problem reported in git-lfs#5064 by updating the
NewManifest() function a third time.  The function once again sets
the maximum number of concurrent transfers to one when the SSH
adapter is in use, but now only when SSH multiplexing is not enabled,
as might occur when using an SSH agent other than the ssh(1) command.

When we made this most recent change, though, we neither updated the
original comment nor moved it to appear prior to the relevant
conditional block in the NewManifest() function, so we make those
corrections now.

In PR git-lfs#6241 we recently adopted a change which made the default
value of the "lfs.concurrentTransfers" configuration option
variable and scaled to three times the number of available CPUs.

This change benefits users with multi-core CPUs when they transfer
Git LFS objects over HTTP, since we start multiple concurrent
threads (i.e., "goroutines") to make Git LFS Batch API requests
and object transfer requests in parallel.

However, the "lfs.concurrentTransfers" configuration option also
controls the number of parallel object transfers when using
protocols other than HTTP, and in these cases, we spawn multiple
separate child processes to perform the transfer operations.

For example, when using the "pure" SSH-only Git LFS object transfer
protocol, we may run multiple instances of the ssh(1) command,
unless SSH multiplexing is not enabled.  (Note that we may also
use another SSH agent, depending on what has been configured via
the "core.sshCommand" option and the GIT_SSH or GIT_SSH_COMMAND
environment variables.)

When multiplexing is enabled, we set the ssh(1) command's ControlMaster
option so that all the separate processes we start will share a single
underlying SSH connection.  We also only start SSH agent processes
on demand in this case.  When transferring many objects, though, we
will start multiple processes, up to the limit specified by the
"lfs.concurrentTransfers" configuration option.

As another example, when using our custom transfer protocol we always
start multiple separate instances of the transfer agent program, which
may either be our "git lfs standalone-file" command or an agent
configured with the "lfs.customTransfer.*" options.  In the first case,
we only start a single process, but otherwise we always start exactly
as many processes as is specified by the "lfs.concurrentTransfers"
option, unless the "lfs.concurrentTransfers.<name>.concurrent" option
is set to "false".

Finally, even when using our standard HTTP-based transfer adapter,
we may start multiple threads in situations where we do not need
them all.

For instance, in cases where the "git lfs smudge" command is used
instead of the more-efficient "git lfs filter-process" command, each
invocation of the "git lfs smudge" command will transfer only a
single object, but will nevertheless start the number of threads
specified by the "lfs.concurrentTransfers" option.

Typical modern installations of Git LFS do not use the "git lfs smudge"
command, but if the "filter.lfs.process" Git configuration option is
missing, or if a version of Git older than v2.11.0 is in use, then
the "git lfs smudge" command may still be utilized.

Even when the "git lfs filter-process" command is used, when just
a small number of objects need to be transferred, we will still start
the number of threads specified by the "lfs.concurrentTransfers"
option.

In all these instances, if we set the default value of the
"lfs.concurrentTransfers" option based on the number of CPUs then we
may start many more processes or threads than we did prior to the
changes in PR git-lfs#6241.  This may have unexpected and negative
consequences for our users, particularly in those cases where we
spawn separate processes to transfer objects, such as when a
custom transfer agent is configured.

Ideally, we would address all of these issues by refactoring our
HTTP and custom transfer adapters to start threads or processes only
on demand, as the SSH transfer adapter already does, while also
introducing new configuration options to better set limits on the
number of transfer agent processes we spawn as distinct from
the number of threads we start during HTTP object transfers.

As we expect to make a v3.8.0 release shortly, though, refactoring
work of this nature is out of scope for the near term.  We therefore
now reverse the key change from PR git-lfs#6241, and set the default value
of the "lfs.concurrentTransfers" option to its historical value of 8.

Looking forward, we should write a proposal to discuss how to implement
any new configuration options such that they respect the historical
meaning of the "lfs.concurrentTransfers" option.  As one consideration,
if a user has explicitly set the "lfs.concurrentTransfers" option but
has not set any of the new options, then the "lfs.concurrentTransfers"
option's value should be understood as a maximum limit for the number
of threads or processes we start during object transfers.  On the
other hand, if a user sets one of our new options but not the
"lfs.concurrentTransfers" option, then we might allow its value to
override the default value of the "lfs.concurrentTransfers" option.