ATM, git-annex asks for a possibly stored credential for a remote per each file, even if they are to come from the same remote. IMHO it should cache for that get run the password to be reused if some next file is to be obtained from the same (git) remote.
lena:/tmp
$> git clone http://data.pymvpa.org/tmp/sampleds/.git/
Cloning into 'sampleds'...
Username for 'http://data.pymvpa.org': yoh
Password for 'http://yoh@data.pymvpa.org':
Fetching objects: 50, done.
$> cd sampleds
$> git annex get *dat
Username for 'http://data.pymvpa.org': yoh
Password for 'http://yoh@data.pymvpa.org':
get 123.dat (from origin...)
Username for 'http://data.pymvpa.org': yoh
Password for 'http://yoh@data.pymvpa.org':
ok
get 1.dat (from origin...)
Username for 'http://data.pymvpa.org': ^C
and annex --debug shows that each password prompt due to
[2022-09-06 16:58:31.99087915] (Utility.Process) process [139934] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","credential","fill"]
and wondered if such excessive prompting could be avoided without engaging git credentials caching functionality.
Is this a git-lfs special remote, or a git remote with an annex/objects directory? Probably does not matter, but also is unclear.
git credentialis doing the prompting here, and it supports caching, if you choose to enable that, by eggit config credential.helper cache.It feels redundant to add another layer of caching to git's existing cache. On the other hand, I suppose that
git pullcan make multiple http accesses and reuse the same credential for them, so that's kind of a precedent for caching during the lifetime of the process.Seems that the git-lfs special remote already implements something like this. When discovering the LFS endpoint, it checks if a credential is needed, and that credential is included in the endpoint, so will be used for all requests, and it only prompts once.
So it's only the git remote when accessing annex/objects over http that prompts repeatedly for credentials.
I've implemented this, and a get of multiple files will prompt once.
However, there is one case where the password is prompted twice. In a freshly cloned repo, where you have not run
git-annex initmanually,git-annex get foowill prompt twice.That is because autoinit causes
git-annex init --autoenableto be run, and that infortunately probes for the UUID of the http remote, which needs the password. Since the cache is necessarily only for a single process, that subprocess adds an additional prompt.There might also be other cases where git-annex starts subprocesses, that legitimately each need to prompt once for the password. I expect that, when
git-annex transferreris used (due to annex.stalldetection being configured), and -J is used, each transferrer process will end up prompting once for the password.I don't think it makes sense to convert this from a simple in-process cache to a cache that is shared amoung all subprocesses. That would reimplement what
git-credential-cachealready does. And if you need that, you can just enable it.But I would like to fix the autoinit case to not prompt twice, and am leaving this open for now to do that.
Fixed the autoinit case.
I'm going to close this as done, despite the cases mentioned above where subprocesses might redundantly prompt for the credentials.
Another reason to not worry about those is that
git-annex syncrunsgit fetchandgit push(more than once), so there will be several password prompts there. So when git-annex runs a git-annex subprocess, it follows it's just as ok for it to do its own password prompts as it is for a git subprocess to do so. The solution to either is certianly to enable git's credential cache. So the scope of this todo has to be limited to prompting done by a single git-annex process.