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

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 24, 2025, 20:18 UTC
Message-ID: <xmqq34h8x8wg.fsf@gitster.g>
In-Reply-To: <CAL_k5jZkYG0evQ2L+bCNvPAnePj=WdU-36GujfjRDwm3iX8ynQ@mail.gmail.com>

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

Show 9 quoted lines

> 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?