{"thread":{"id":"66708","subject":"[BUG] grep --recurse-submodules <tree> dies on a directory inside a submodule","startedAt":"2026-10-29T19:52:07Z","lastAt":"2026-10-30T10:26:35Z","messageCount":2,"participants":["Root","Patrick Steinhardt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"556820","messageId":"CAMtVYEjWd2XwJpXdk3PV2jbNdoOaqS3x+08EMu5byy55RxfRmA@mail.gmail.com","threadId":"66708","inReplyTo":null,"subject":"[BUG] grep --recurse-submodules <tree> dies on a directory inside a submodule","fromName":"Root","fromEmail":"rootminus0x1@gmail.com","sentAt":"2026-10-29T19:52:07Z","receivedAt":"2026-10-29T19:52:07Z","isPatch":false,"sender":{"key":"rootminus0x1@gmail.com","avatar":null},"body":"Hi,\n\nSince Git 2.56.0, \"git grep --recurse-submodules <pattern> <tree>\"\ndies when it reaches a directory inside a submodule:\n    fatal: unable to read tree (<id of that directory's tree>)\n\nThe working-tree form (\"git grep --recurse-submodules <pattern>\") is\nnot affected, and neither is a submodule with no directories. Our CI\npassed the same case on 2.55.0.\n\nWhat did you do before the bug happened? (Steps to reproduce your issue)\n\n    #!/bin/sh\n    set -e\n    work=$(mktemp -d)\n    cd \"$work\"\n\n    git init -q sub\n    mkdir sub/dir\n    echo hello >sub/top\n    echo hello >sub/dir/nested\n    git -C sub add top dir/nested\n    git -C sub -c user.name=t -c user.email=t@t commit -qm sub\n\n    git init -q super\n    git -C super -c protocol.file.allow=always \\\n        submodule --quiet add \"$work/sub\" sub\n    git -C super -c user.name=t -c user.email=t@t commit -qm super\n\n    git -C super grep --recurse-submodules -e hello HEAD\n\nWhat did you expect to happen? (Expected behavior)\n\n    HEAD:sub/dir/nested:hello\n    HEAD:sub/top:hello\n\nWhat happened instead? (Actual behavior)\n\n    fatal: unable to read tree (935cff11a11f8734cf4e0d40955d1e0e5c12038e)\n\nwith exit status 128. The id is that of the tree of sub/dir.\n\nWhat's different between what you expected and what actually happened?\n\nThe search dies instead of listing the matches. It dies at the first\ndirectory inside the submodule, so nothing in that submodule is\nsearched from there on.\n\nAnything else you want to add:\n\nIt starts with 93cd344e34 (builtin/grep: stop registering submodule\nODB as source, 2026-09-11). Built from source (with NO_RUST=1), its\nparent a532feba89 prints the expected output above, and 93cd344e34\ndies with the same message and the same tree id.\n\nIn grep_tree(), each subdirectory is read from the superproject's\nobject database (builtin/grep.c line 656 in v2.56.0):\n    data = odb_read_object(the_repository->objects,\n                           &entry.oid, &type, &size);\n\nThe function's repository is opt->repo, and grep_submodule() sets that\nto the submodule. grep_submodule() reads the submodule's root tree\nfrom subrepo->objects, which is why a submodule with no directories is\nsearched correctly. Before 93cd344e34 the submodule's object database\nwas registered as a source of the main one, so the lookup above found\nthe tree there.\n\nOn v2.56.0, reading from repo->objects on that line instead makes the\nreproduction print the expected output. I have not run the test suite\nwith that change.\n\ngrep_cache() reads sparse-directory index entries the same way, on\nline 563:\n    data = odb_read_object(the_repository->objects, &ce->oid, &type, &size);\nI have not checked whether a submodule with a sparse index fails.\n\nBoth lines are unchanged on master, next and seen as of 2026-10-29.\n\nWe met this in CI: GitHub's ubuntu-22.04 runner image moved from git\n2.55.0 to 2.56.0 between its 2026-10-12 and 2026-10-25 releases.\n\n[System Info]\ngit version: git version 2.56.0\ncpu: x86_64\nno commit associated with this build\nsizeof-long: 8\nsizeof-size_t: 8\nshell-path: /bin/sh\nrust: enabled\nfeature: fsmonitor--daemon\ngettext: enabled\nlibcurl: 7.81.0\nzlib: 1.2.11\nSHA-1: SHA1_DC\nSHA-256: SHA256_BLK\ndefault-ref-format: files\ndefault-hash: sha1\nuname: Linux 7.0.0-38-generic #38~24.04.4-Ubuntu SMP PREEMPT_DYNAMIC\nMon Sep 14 16:37:11 UTC 2 x86_64\ncompiler info: gnuc: 11.4\nlibc info: glibc: 2.35\n$SHELL (typically, interactive shell): <unset>\n\n(Ubuntu 22.04 in a container, git 2.56.0 from the git-core PPA; the\nkernel line is the host's.)\n\n\n[Enabled Hooks]\nnot run from a git repository - no hooks to show\n\nI hope this helps fix the bug (if it is indeed a bug). Let me know if\nyou need any more\n\nRegards\n\n"},{"id":"556882","messageId":"auRw2yZv6p4MKwNJ@pks.im","threadId":"66708","inReplyTo":"CAMtVYEjWd2XwJpXdk3PV2jbNdoOaqS3x+08EMu5byy55RxfRmA@mail.gmail.com","subject":"Re: [BUG] grep --recurse-submodules <tree> dies on a directory inside a submodule","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2026-10-30T10:26:35Z","receivedAt":"2026-10-30T10:26:35Z","isPatch":false,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"Hi,\n\nOn Thu, Oct 29, 2026 at 07:52:07PM +0000, Root wrote:\n> Hi,\n> \n> Since Git 2.56.0, \"git grep --recurse-submodules <pattern> <tree>\"\n> dies when it reaches a directory inside a submodule:\n>     fatal: unable to read tree (<id of that directory's tree>)\n> \n> The working-tree form (\"git grep --recurse-submodules <pattern>\") is\n> not affected, and neither is a submodule with no directories. Our CI\n> passed the same case on 2.55.0.\n> \n> What did you do before the bug happened? (Steps to reproduce your issue)\n> \n>     #!/bin/sh\n>     set -e\n>     work=$(mktemp -d)\n>     cd \"$work\"\n> \n>     git init -q sub\n>     mkdir sub/dir\n>     echo hello >sub/top\n>     echo hello >sub/dir/nested\n>     git -C sub add top dir/nested\n>     git -C sub -c user.name=t -c user.email=t@t commit -qm sub\n> \n>     git init -q super\n>     git -C super -c protocol.file.allow=always \\\n>         submodule --quiet add \"$work/sub\" sub\n>     git -C super -c user.name=t -c user.email=t@t commit -qm super\n> \n>     git -C super grep --recurse-submodules -e hello HEAD\n> \n> What did you expect to happen? (Expected behavior)\n> \n>     HEAD:sub/dir/nested:hello\n>     HEAD:sub/top:hello\n> \n> What happened instead? (Actual behavior)\n> \n>     fatal: unable to read tree (935cff11a11f8734cf4e0d40955d1e0e5c12038e)\n> \n> with exit status 128. The id is that of the tree of sub/dir.\n\nindeed, thanks for the report. I've sent patches to fix this via [1].\n\nThanks!\n\nPatrick\n\n[1]: <20261030-pks-grep-recurse-submodule-v1-0-d4eb5c87d8fb@pks.im>\n\n"}]}