David Turner <[email protected]> writes:
> @@ -16,8 +16,26 @@ cmp_cache_tree () {
> # We don't bother with actually checking the SHA1:
> # test-dump-cache-tree already verifies that all existing data is
> # correct.
> -test_shallow_cache_tree () {
> - printf "SHA (%d entries, 0 subtrees)\n" $(git ls-files|wc -l) >expect
> &&
> +generate_expected_cache_tree () {
> + dir="$1${1:+/}" &&
> + parent="$2" &&
> + # ls-files might have foo/bar, foo/bar/baz, and foo/bar/quux
> + # We want to count only foo because it's the only direct child
> + subtrees=$(git ls-files|grep /|cut -d / -f 1|uniq) &&
> + subtree_count=$(echo "$subtrees"|awk '$1 {++c} END {print c}') &&
> + entries=$(git ls-files|wc -l) &&
> + printf "SHA $dir (%d entries, %d subtrees)\n" $entries $subtree_count &&
> + for subtree in $subtrees
> + do
> + cd "$subtree"
> + generate_expected_cache_tree "$dir$subtree" $dir || return 1
> + cd ..
If the || return 1 ever triggers, would the main test process end up
in an unexpected place? A test piece executes test_cache_tree whose
control eventually reaches here and returns failure; the next test
piece will start at a wrong directory, no?
> + done &&
> + dir=$parent
> +}
> +
> +test_cache_tree () {
> + generate_expected_cache_tree >expect &&
> cmp_cache_tree expect
> }
>
> @@ -33,14 +51,14 @@ test_no_cache_tree () {
> cmp_cache_tree expect
> }
>
> -test_expect_failure 'initial commit has cache-tree' '
> +test_expect_success 'initial commit has cache-tree' '
> test_commit foo &&
> - test_shallow_cache_tree
> + test_cache_tree
> '
>
> test_expect_success 'read-tree HEAD establishes cache-tree' '
> git read-tree HEAD &&
> - test_shallow_cache_tree
> + test_cache_tree
> '
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
