Re: Bug report: parallel fetch tries to unlock SSH keys over and over again

[Junio C Hamano <gitster@pobox.com>]

Perez-Lopez Áron Ricardo <perez.aron@gmail.com> writes:

> What did you do before the bug happened? (Steps to reproduce your issue)
> git fetch --all --tags --prune --jobs=10
>
> What did you expect to happen? (Expected behavior)
> Being asked for the password of my SSH key, then git updating all of
> the remotes.
>
> What happened instead? (Actual behavior)
> I get asked for my SSH key many times over, and the fetch does not succeed.

It is hard to tell without seeing how many repositories the above
"--all" expands to (but I'd assume it is way more than 10), if they
share the same credentials or going to different site that requires
different SSH keys but these keys share the same passphrase, etc.

Assuming that they all go to the same host that wants the same SSH
keys, and assuming that you are using ssh agent, if the symptom were
the fetch *does* succeed, but being asked for the passphrase to
unlock the same key number of times, then I can sort of see why it
would be problematic and why it might help to wait for the first
connection to successfully open before starting the other 9 jobs as
you instructed "git fetch" to spawn.

But if the symptom is that the fetch does *not* succeed [*], a
simpler explanation of the symptom may be that the passphrase given
was simply misspelt and/or there is no ssh agent involved that loads
the passphrases and caches them on demand.

FWIW, I push over openssh connection to many sites, but as far as I
know, I need to say "ssh-add" to tell the agent what keys should be
cached and what their passphrases are *well* *before* I initiate
anything that requires ssh connections like "git push".

Sorry that my response is not an answer, but I have never dealt with
a SSH setting where the AddKeysToAgent directive is active.  Others
may have better ideas, but I wonder what good would "wait for the
first one" do, as a general "fix".  Git does not even know what
relationship the underlying SSH connections to these other 9
repositories would have to the connection to the site that hosts the
first repository, and the first one might happen to be hosted at a
site using a completely unrelated SSH key from the rest, in which
case it simply is wasting time to make the other 9 wait.


[footnote]

 * ... and since the command line is using "--all", what does it
   really mean that it does *not* succeed?  Some fetches but some
   others don't?