more completely solve catKey memory leak

Done using a mode witness, which ensures it's fixed everywhere.

Fixing catFileKey was a bear, because git cat-file does not provide a
nice way to query for the mode of a file and there is no other efficient
way to do it. Oh, for libgit2..

Note that I am looking at tree objects from HEAD, rather than the index.
Because I cat-file cannot show a tree object for the index.
So this fix is technically incomplete. The only cases where it matters
are:

1. A new large file has been directly staged in git, but not committed.
2. A file that was committed to HEAD as a symlink has been staged
   directly in the index.

This could be fixed a lot better using libgit2.
This commit is contained in:
Joey Hess 2013-09-19 16:30:37 -04:00
parent f26c996dc6
commit 006cf7976f
10 changed files with 71 additions and 27 deletions

4
debian/changelog vendored
View file

@ -18,8 +18,8 @@ git-annex (4.20130912) UNRELEASED; urgency=low
numcopies levels. (--fast avoids calculating these)
* gcrypt: Ensure that signing key is set to one of the participants keys.
* webapp: Show encryption information when editing a remote.
* sync, pre-commit, indirect: Avoid unnecessarily catting non-symlink
files from git, which can be so large it runs out of memory.
* Avoid unnecessarily catting non-symlink files from git, which can be
so large it runs out of memory.
-- Joey Hess <joeyh@debian.org> Thu, 12 Sep 2013 12:14:46 -0400