2011-11-08 16:23:03 +00:00
|
|
|
a <!-- (a suggestion for introducing severity tags on bugs,
|
2011-06-14 17:01:13 +00:00
|
|
|
feel free to discard) --> issue: `git annex initremote` (in particular, adding
|
|
|
|
|
a key as described in [[encryption]] -- `git annex initremote my_remote
|
|
|
|
|
encryption=my_key`) seems to iterate over the `.git-annex/???/???/*.log` files
|
|
|
|
|
with lstat (tested using strace).
|
|
|
|
|
|
|
|
|
|
in a 50k key git-annex on a slow disk, this takes quite a while, while not
|
|
|
|
|
seeming necessary (it's just re-encrypting the shared secret, is it?).
|
|
|
|
|
|
|
|
|
|
could you verify the observed behavior?
|
2011-06-14 23:05:45 +00:00
|
|
|
|
|
|
|
|
> This is due to `git commit` being called. `git commit` exposes git's
|
|
|
|
|
> rather innefficient handling of the index; in order to make a commit
|
|
|
|
|
> it has to write a new index file, and it does this by scanning every
|
|
|
|
|
> file in the repository. I think that git generally needs its index
|
|
|
|
|
> file handleing overhauled, particularly to deal with repositories with
|
|
|
|
|
> large numbers of files. git-annex is seems to already be running
|
|
|
|
|
> `git commit` in its most efficient mode, by specifying exactly what file
|
|
|
|
|
> to commit. [[done]] --[[Joey]]
|
