On Mon, Feb 21 2022, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > >> This test though will break, as you can see with: >> >> GIT_TEST_DEFAULT_HASH=sha256 ./t3007-ls-files-recurse-submodules.sh >> >> So you'll need at least something like: >> >> diff --git a/t/t3007-ls-files-recurse-submodules.sh b/t/t3007-ls-files-recurse-submodules.sh >> index 3d2da360d17..0fe69da8dcf 100755 >> --- a/t/t3007-ls-files-recurse-submodules.sh >> +++ b/t/t3007-ls-files-recurse-submodules.sh >> @@ -42,10 +42,10 @@ test_expect_success '--stage' ' >> echo brigddsv >submodule/c && >> git -C submodule commit -am "update c again" && >> >> - cat >expect <<-\EOF && >> - 100644 6da7 0 .gitmodules >> - 100644 7898 0 a >> - 100644 6178 0 b/b >> + cat >expect <<-EOF && >> + 100644 $(git rev-parse --short=4 HEAD:.gitmodules) 0 .gitmodules >> + 100644 $(git rev-parse --short=4 HEAD:a) 0 a >> + 100644 $(git rev-parse --short=4 HEAD:b/b) 0 b/b >> 100644 dead9 0 submodule/c >> EOF >> >> But then the problem is that one is dead9 and the other dead6, I was >> just trying to find 4-char prefixes. >> >> But having indulged in all that, I'm now entirely confused about why any >> of this needs to be tested here. >> >> You're adding --stage, which will give us --stage-y output, and it was >> previously incompatible with --recurse-submodules. Having the two >> combine is good! > > I think what this is trying to make sure is that it (1) enabled the > combination and (2) uses the object store of the submodule when > disambiguating names of the objects from the submodule, because the > author suspects that the reason why these two options were made > incompatible in the first place was because long time ago there > wasn't a way to ask "here is an object name---please uniquify in the > context of _that_ repository". So it is understandable to prepare > an object X in a submodule and another object Y in the superproject, > such that the abbreviated name of X in the context of the submodule > is different from the abbreviated name of X in the context of the > superproject (i.e. if X were in the superproject's object store, > because the object names of X and Y share the prefix, it may require > longer prefix to disambiguate from Y), and make sure that the uniquify > is indeed happening in the context of the submodule. > > So, you are only concentrating on (1) but forgetting why the author > wants (2). Indeed. That makes sense, but it would really help to e.g. have the test description make that goal explicit.
