On Wed, Apr 26, 2017 at 10:56:23PM -0500, Samuel Lijin wrote: > I *know* that the changes I'm working on are causing the tests to > fail, but I can't figure out how to induce the failure manually (so > that I can throw gdb at the problem). > > Specifically I'm seeing t5000-tar-tree.sh fail (as a result of adding > extra diff_populate_filespec() calls before the estimate_similarity() > loop in diffcore_rename()) on #52 "set up repository with huge blob" > and #55 "set up repository with far-future commit". > > If I run the commands fed into test_expect_success in t5000, though > (in an empty repo initialized with git init), making sure to use the > binary compiled with the breaking changes, the command doesn't fail, > so I'm clearly missing something in the testing environment setup when > I try to manually reproduce it. > > Can someone point me in the right direction? I've spent some time now > going through t/test-lib.sh and I haven't figured it out yet. I'd usually start by stopping the script at the failed test, going into the repository directory, and then running from there. Like: $ cd t $ ./t5000-tar-tree.sh -v -i -x $ cd trash\ directory.t5000-tar-tree $ gdb --args ../../git whatever-failed That's usually enough to re-create the broken state. Sometimes there are things in the environment, or the test is impacted by your user-level config (test-lib resets $HOME, so it should have no user config). But it's usually easier to just stick a "gdb" temporarily into the test. Note there are some tricks there with redirections and the bin-wrappers script; see the debug() helper in test-lib-functions.sh. -Peff