blob: f60b4d7062ba348a034b0f765b8eaaf3a929a825 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
|
[[!comment format=mdwn
username="joey"
subject="""comment 2"""
date="2018-01-09T19:56:42Z"
content="""
With the above dealt with, the remaining problem is with commands
like `git annex whereis` or `git annex info`, which don't really
any on any remote, but still need to examine the remotes as part of
building the remoteList.
git-annex supports remotes that point to a mount point that might have
different drives mounted at it at different times. So, it needs to
check the git config of the remote each time, to see what repository is
currently there.
Even commands like "whereis" and "info" have output that depends on
what repository a remote is currently pointing to. In some cases,
"whereis" might not output anything that depends on a given remote,
so in theory it could avoid looking at the config of that remote.
And a command like "git annex copy --to origin" doesn't really
need to look at the configs of any other remotes.
But to avoid unncessarily checking the git configs of remotes that a
command does not use would need each use of the current remoteList
to be replaced with something else that does the minimal needed work,
instead of building the whole remoteList. I think this would be quite
complicated.
And, I don't know that it would address the bug report adequequately, even
if it were done. Running `git annex info` would
still block waiting for the automount; `git annex whereis` would
only *sometimes* block, depending on where content is.
So instead of that approach, perhaps a config setting will do?
A per-remote config that tells git-annex that only one repository
should ever be mounted at its location. That would make git-annex
avoid checking the git config of that remote each time, except
when it's actually storing/dropping content on it.
"""]]
|
