avoid redundant prompt for http password in git-annex get that does autoinit

autoEnableSpecialRemotes runs a subprocess, and if the uuid for a git
remote has not been probed yet, that will do a http get that will prompt
for a password. And then the parent process will subsequently prompt
for a password when getting annexed files from the remote.

So the solution is for autoEnableSpecialRemotes to run remoteList before
the subprocess, which will probe for the uuid for the git remote in the
same process that will later be used to get annexed files.

But, Remote.Git imports Annex.Init, and Remote.List imports Remote.Git,
so Annex.Init cannot import Remote.List. Had to pass remoteList into
functions in Annex.Init to get around this dependency loop.
This commit is contained in:
Joey Hess 2022-09-09 14:43:43 -04:00
parent 9621beabc4
commit c62fe5e9a8
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
6 changed files with 44 additions and 13 deletions

View file

@ -31,3 +31,5 @@ and wondered if such excessive prompting could be avoided without engaging `git`
[[!meta author=yoh]]
[[!tag projects/repronim]]
> [[fixed|done]] --[[Joey]]

View file

@ -0,0 +1,19 @@
[[!comment format=mdwn
username="joey"
subject="""comment 4"""
date="2022-09-09T18:39:06Z"
content="""
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 sync` runs `git fetch` and `git
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.
"""]]