Re: [PATCH v5 4/4] cache-tree: Write updated cache-tree after commit

[Junio C Hamano <gitster@pobox.com>]

David Turner <dturner@twopensource.com> 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
>  '