Please describe the problem.

When doing

git checkout 3b18836

on a very large repository, where tens of thousands of files will be changed, I get many

error: external filter 'git-annex filter-process' failed error: git-annex filter-process died of signal 15

and finally

git-annex: git: createProcess: runInteractiveProcess: pipe: resource exhausted (Too many open files) fatal: the remote end hung up unexpectedly

What steps will reproduce the problem?

git checkout on a really big commit.

What version of git-annex are you using? On what operating system?

The system and all the SW should be up to date.

% git --version
git version 2.34.1

% git annex version
git-annex version: 10.20220322-1~ndall+1 build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.0 key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X* remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external operating system: linux x86_64 supported repository versions: 8 9 10 upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10 local repository version: 9

% uname -a
Linux 5.15.0-33-generic #34-Ubuntu SMP Wed May 18 13:34:26 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

% cat /etc/os-release
PRETTY_NAME="Ubuntu 22.04 LTS" NAME="Ubuntu" VERSION_ID="22.04" VERSION="22.04 LTS (Jammy Jellyfish)" VERSION_CODENAME=jammy ID=ubuntu ID_LIKE=debian HOME_URL="https://www.ubuntu.com/" SUPPORT_URL="https://help.ubuntu.com/" BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/" PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy" UBUNTU_CODENAME=jammy

The computer has 128GB of main memory, and so is not running out of that.

This is a large repository:

du -sh . p 43G .

(62)% du -sh .git
42G .git

(63)% du -sh .git/annex
19G .git/annex

% git gc
Enumerating objects: 375565, done. Counting objects: 100% (375565/375565), done. Delta compression using up to 12 threads Compressing objects: 100% (153675/153675), done. Writing objects: 100% (375565/375565), done. Total 375565 (delta 215701), reused 364628 (delta 207259), pack-reused 0 73.38s real 97.69s user 4.93s system 139% 0,0 socket 13753 mem git gc

I'm trying to recover from a mess caused by creating a new remote repository, making it shallow to save space, and updating it by mounting it on a local system with sshfs, etc. That caused an unintended rebase messing things up, e.g., git log shows most of the commits vanished (merged?). So I was trying to go back to an earlier, good, commit. However that requires changing, basically, everything. And that seems to be too big a change for git annex to process.

FWIW, I'm not using lfs.

Please provide any additional information below.

# If you can, paste a complete transcript of the problem occurring here.
# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log


# End of transcript or log.

Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)

Otherwise, it's great.