diff options
author | 2011-06-14 19:05:45 -0400 | |
---|---|---|
committer | 2011-06-14 19:05:45 -0400 | |
commit | 64d6520704fde80ee1584cacd4a16a54d88970fd (patch) | |
tree | 3047b17d9842cf193a5c3a6e3172e4c9b3bfe1c9 | |
parent | f4609a5d288525abbb47e361194601d21684df8e (diff) |
git is slow
-rw-r--r-- | doc/bugs/git_annex_initremote_walks_.git-annex.mdwn | 9 |
1 files changed, 9 insertions, 0 deletions
diff --git a/doc/bugs/git_annex_initremote_walks_.git-annex.mdwn b/doc/bugs/git_annex_initremote_walks_.git-annex.mdwn index 6e3a60e3b..2457057c8 100644 --- a/doc/bugs/git_annex_initremote_walks_.git-annex.mdwn +++ b/doc/bugs/git_annex_initremote_walks_.git-annex.mdwn @@ -8,3 +8,12 @@ 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]] |