diff options
Diffstat (limited to 'doc/bugs/git_annex_initremote_walks_.git-annex.mdwn')
| -rw-r--r-- | doc/bugs/git_annex_initremote_walks_.git-annex.mdwn | 19 |
1 files changed, 0 insertions, 19 deletions
diff --git a/doc/bugs/git_annex_initremote_walks_.git-annex.mdwn b/doc/bugs/git_annex_initremote_walks_.git-annex.mdwn deleted file mode 100644 index acd369bde..000000000 --- a/doc/bugs/git_annex_initremote_walks_.git-annex.mdwn +++ /dev/null @@ -1,19 +0,0 @@ -a <!-- (a suggestion for introducing severity tags on bugs, -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? - -> 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]] |