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:
parent
f26c996dc6
commit
006cf7976f
10 changed files with 71 additions and 27 deletions
4
debian/changelog
vendored
4
debian/changelog
vendored
|
@ -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
|
||||
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue