Jeff King <peff@xxxxxxxx> writes: > On Mon, May 18, 2015 at 10:46:50AM -0700, Junio C Hamano wrote: > >> The test framework is aware of the fact that it needs to help the >> people who are debugging the scripts. The support is limited to the >> case in which you run it under the -i option, i.e. >> >> $ cd t >> $ sh ./t5520-pull.sh -i -v >> >> will refrain from running test_when_finished scripts when the test >> piece fails. Even though this is only limited to -i, I found it >> often sufficient for debugging. > > If you don't use "-i", you are pretty much screwed anyway, because the > subsequent tests will stomp all over the state of the test directory. Yeah. > Many a head-scratching session has been caused by looking at the wrong > state, and these days my go-to options for debugging a test are "-v -i". > But since we are talking about it in a related thread, I will advertise > the new "-x" here, too. :) Yes, thanks for "-x". That has been very helpful. > As a side note, I've also considered better support for running the > debugger on git commands inside a test (right now, I usually stick a > "gdb --args" in the pipeline, but you have to remember to run with "-v", > and to redirect stdin appropriately). Do other people have this > annoyance, too? I usually tweak the script and have it stop before the offending test, and then go through the steps in the test manually X-<. If it can be more automated, that would be great. I haven't been ambitious enough to even attempt it so do not have anything to add to the implementation ideas at this point. > I'm vaguely thinking of something like putting debug support into > bin-wrappers/git, but activating it only for certain tests (so you could > say "t5520-pull.sh --gdb=10", and git would start under the debugger > only for test 10). I think we'd also have to use gdbserver for I/O > sanity, and maybe provide short script to do: > > gdb -ex "target remote localhost:$some_port" "$TEST_DIRECTORY"/../git > > That still doesn't cover all cases (when git spawns an external command, > you probably want to run the debugger on that; likewise, I have a > git-remote-debug hack for debugging remote-curl). I suspect with clever > use of gdb options that you could convince the original gdb invocation > to end up tracing the process you care about, though. > > -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html