Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: >>> test_expect_success 'ls-tree --abbrev=5' ' >>> git ls-tree --abbrev=5 $tree >current && >>> - sed -e "s/ $_x05[0-9a-f]* / X /" <current >check && >>> + sed -e "s/ [0-9a-f]* / X /" <current >check && >>> cat >expected <<\EOF && >>> 100644 blob X 1.txt >>> 100644 blob X 2.txt >> >> This one is particularly iffy. The --abbrev=5 test is designed to >> ensure that the resulting abbreviated object names are at least 5 >> hexdigits long, even when the repository is so small that only 4 >> hexdigits are sufficient to avoid ambiguity, while allowing the >> output to be longer than specified 5 (when 5 turns out to be >> insufficient for disambiguation). >> >> So, I dunno. > > Yes, I think this patch should be dropped. Do you mind just dropping the > 4/4 and having it be a 3-patch series? I can also re-submit a v2 like > that if it's easier... As long as the earlier three are good to go, I can just cut the tip of the branch, or just drop it all now and send a three-patch series after the release. Either is fine. > My assumption in writing this patch was that it was fine because we test > the details of abbrev behavior somewhere else, surely... I expected that the test whose title is "ls-tree --abbrev=5" is targetted towards testing the details of abbrev behaviour. Isn't that the case? Is the same assumption brought silent breakages to the other two patches to the tests, by chance? I only gave cursory look on them and don't think anybody else looked at them carefully.
