In the test suite for Bitbucket Server, we have a test repository[1]
which has a commit that has a .gitmodules file that lists 3
submodules, each of which has an entry in the tree with "Subproject
commit <SHA>".
The submodules aren't fetched (at least one of them doesn't actually
exist anywhere to fetch), but running git ls-tree in Git 2.35.1 and
prior shows the expected tree data:
$ git ls-tree -r -l ecf42d8adc4d7eb4386e37882d053704067712d4: --
100644 blob c0de405f50ea72f9d2b973dd504671ba63ea7189 346 .gitmodules
100644 blob 493021b1c9e0ecfebcd5ebce646a44138bc60b39 20
add_file/add_file.txt
100644 blob d8c00a7fe6eb6a00378e103a46e3c472c084a949 25
basic_branching/file.txt
100644 blob 927b01c060cf0dc5036e19abeab8e332d9075ea0 167 binary/B.zip
100644 blob 72555d02a139700be930a6734b57c5fab84512b9 167 binary/C.zip
100644 blob 72555d02a139700be930a6734b57c5fab84512b9 167 binary/D.zip
100644 blob 668076c308990933c2df66efb87b946704252486 46
branch_mod_merge/file.txt
100644 blob b1d99e581f0bb8138b8997f9268294e41faee05b 33
modification/mod_file.txt
100644 blob 46fa903c8af8a92c2714a47ae5a341a99c2ee3b2 18 moved_dir/file.txt
100644 blob f49abb7d6c366e6f83470e36439bc162234d7963 24
mv_file/moved_file.txt
100644 blob 2e6b03cbbe90d3c9afcfc98967a5a71b4c9cff1a 66
out_of_order/file.txt
160000 commit 0ac826865ce7e8bc76022d49424f52e09b16dc87 -
submodule/atlassian-refapp
160000 commit 92b18c97d9d92d2bd02cfd1d268f22fddddafb67 -
submodule/bamboo-git-plugin
160000 commit 996b4f5a7e242a29fe573582d98f5174142bb97c - submodule/stash
120000 blob 4cbb553f3f4ac2ee7b01ff6c951d6bf583c39c15 10 symlink/link.txt
100644 blob 57a3592bb2cf8e76e2faef7660945a2fe0e24360 27 symlink/target.txt
The same ls-tree command in 2.36.0-rc0 fails:
$ /opt/git/2.36.0-rc0/bin/git ls-tree -r -l
ecf42d8adc4d7eb4386e37882d053704067712d4: --
100644 blob c0de405f50ea72f9d2b973dd504671ba63ea7189 346 .gitmodules
100644 blob 493021b1c9e0ecfebcd5ebce646a44138bc60b39 20
add_file/add_file.txt
100644 blob d8c00a7fe6eb6a00378e103a46e3c472c084a949 25
basic_branching/file.txt
100644 blob 927b01c060cf0dc5036e19abeab8e332d9075ea0 167 binary/B.zip
100644 blob 72555d02a139700be930a6734b57c5fab84512b9 167 binary/C.zip
100644 blob 72555d02a139700be930a6734b57c5fab84512b9 167 binary/D.zip
100644 blob 668076c308990933c2df66efb87b946704252486 46
branch_mod_merge/file.txt
100644 blob b1d99e581f0bb8138b8997f9268294e41faee05b 33
modification/mod_file.txt
100644 blob 46fa903c8af8a92c2714a47ae5a341a99c2ee3b2 18 moved_dir/file.txt
100644 blob f49abb7d6c366e6f83470e36439bc162234d7963 24
mv_file/moved_file.txt
100644 blob 2e6b03cbbe90d3c9afcfc98967a5a71b4c9cff1a 66
out_of_order/file.txt
160000 commit 0ac826865ce7e8bc76022d49424f52e09b16dc87 -
submodule/atlassian-refapp
error: Could not read 0ac826865ce7e8bc76022d49424f52e09b16dc87
fatal: Invalid commit 0ac826865ce7e8bc76022d49424f52e09b16dc87 in
submodule path submodule/atlassian-refapp
Bisecting the error selects:
$ git bisect good
9c4d58ff2c385f49585197c8650356955e1fa02e is the first bad commit
commit 9c4d58ff2c385f49585197c8650356955e1fa02e
Author: Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx>
Date: Wed Mar 23 17:13:15 2022 +0800
ls-tree: split up "fast path" callbacks
Make the various if/else in the callbacks for the "fast path" a lot
easier to read by just using common functions for the parts that are
common, and have per-format callbacks for those parts that are
different.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx>
Signed-off-by: Teng Long <dyroneteng@xxxxxxxxx>
Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx>
builtin/ls-tree.c | 199 ++++++++++++++++++++++++++++++++++--------------------
1 file changed, 125 insertions(+), 74 deletions(-)
(I've CC'd Ævar and Teng on this message.)
Looking at the changes in that commit I see differences in the
handling for long listings, so I tried removing the -l. At that point,
the command works again:
$ /opt/git/2.36.0-rc0/bin/git ls-tree -r
ecf42d8adc4d7eb4386e37882d053704067712d4: --
100644 blob c0de405f50ea72f9d2b973dd504671ba63ea7189 .gitmodules
100644 blob 493021b1c9e0ecfebcd5ebce646a44138bc60b39 add_file/add_file.txt
100644 blob d8c00a7fe6eb6a00378e103a46e3c472c084a949 basic_branching/file.txt
100644 blob 927b01c060cf0dc5036e19abeab8e332d9075ea0 binary/B.zip
100644 blob 72555d02a139700be930a6734b57c5fab84512b9 binary/C.zip
100644 blob 72555d02a139700be930a6734b57c5fab84512b9 binary/D.zip
100644 blob 668076c308990933c2df66efb87b946704252486 branch_mod_merge/file.txt
100644 blob b1d99e581f0bb8138b8997f9268294e41faee05b modification/mod_file.txt
100644 blob 46fa903c8af8a92c2714a47ae5a341a99c2ee3b2 moved_dir/file.txt
100644 blob f49abb7d6c366e6f83470e36439bc162234d7963 mv_file/moved_file.txt
100644 blob 2e6b03cbbe90d3c9afcfc98967a5a71b4c9cff1a out_of_order/file.txt
160000 commit 0ac826865ce7e8bc76022d49424f52e09b16dc87
submodule/atlassian-refapp
160000 commit 92b18c97d9d92d2bd02cfd1d268f22fddddafb67
submodule/bamboo-git-plugin
160000 commit 996b4f5a7e242a29fe573582d98f5174142bb97c submodule/stash
120000 blob 4cbb553f3f4ac2ee7b01ff6c951d6bf583c39c15 symlink/link.txt
100644 blob 57a3592bb2cf8e76e2faef7660945a2fe0e24360 symlink/target.txt
Given the command works without -l, and all -l is supposed to do is
add sizes to blobs, it seems like something has regressed in the logic
that decides whether to continue recursing or move on to the next
sibling?
Can someone else whose C is a little less rusty check this and see if
it's a bug? It almost seems like it _has_ to be, though. Bitbucket
Server manages bare repositories which often include submodules, but
none of those submodules (even assuming they're valid, which is not
always the case for repositories in the wild) are ever _fetched_ into
that bare repository. That implies this would always fail in any
repository that contains submodules referencing other repositories.
Best regards,
Bryan Turner
[1] https://packages.atlassian.com/maven/com/atlassian/stash/git/subrepositories/1.0/subrepositories-1.0.zip
is a zipped bare repository that contains the ecf42d8 commit used
above
