Re: t4216-log-bloom.sh broken ?

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

Torsten Bögershausen <tboegi@web.de> writes:

> ++ check_corrupt_graph BDAT clear 00000000
> ++ corrupt_graph BDAT clear 00000000
> ++ graph=.git/objects/info/commit-graph
> ++ test_when_finished 'rm -rf .git/objects/info/commit-graph'
> ++ test 0 = 0
> ++ test_cleanup='{ rm -rf .git/objects/info/commit-graph
> 		} && (exit "$eval_ret"); eval_ret=$?; :'
> ++ git commit-graph write --reachable --changed-paths
> ++ corrupt_chunk_file .git/objects/info/commit-graph BDAT clear 00000000
> ++ fn=.git/objects/info/commit-graph
> ++ shift
> ++ perl /Users/tb/NoBackup/projects/git/git.pu/t/lib-chunk/corrupt-chunk-file.pl BDAT clear 00000000
> ++ command /usr/bin/perl /Users/tb/NoBackup/projects/git/git.pu/t/lib-chunk/corrupt-chunk-file.pl BDAT clear 00000000
> ++ /usr/bin/perl /Users/tb/NoBackup/projects/git/git.pu/t/lib-chunk/corrupt-chunk-file.pl BDAT clear 00000000
> ++ mv .git/objects/info/commit-graph.tmp .git/objects/info/commit-graph
> override r--r--r--  tb/staff for .git/objects/info/commit-graph? (y/n [n]) not overwritten

Another probing question.  Do t5318, t5319, t5324, and t5328 pass?

The "mv" is part of the corrupt_chunk_file helper is used by this:

    corrupt_graph () {
            graph=.git/objects/info/commit-graph &&
            test_when_finished "rm -rf $graph" &&
            git commit-graph write --reachable --changed-paths &&
            corrupt_chunk_file $graph "$@"
    }

and reads like this:

    corrupt_chunk_file () {
            fn=$1; shift
            perl "$TEST_DIRECTORY"/lib-chunk/corrupt-chunk-file.pl \
                    "$@" <"$fn" >"$fn.tmp" &&
            mv "$fn.tmp" "$fn"
    }

If the final "mv" is what is failing in the above trace, the test
tried to corrupt the objects/info/commit-graph file, expecting that
later steps will notice breakage.  But if the broken file written in
commit-graph.tmp failed to become the final commit-graph, later
steps will see healthy graph file and it is understandable that we
do not see any breakage that we expect, thus failing the test.

Is "mv" somehow configured to always go interactive on that box and
on that box alone?  For example if you have ~/bin/mv that does
something silly like

	#!/bin/bash
	exec /bin/mv -i "$@

and have ~/bin early in $PATH, it may be sufficient to explain the
error we see (I am not claiming that is the only way to cause this
test failure; it is just one possible one).