From: Junio C Hamano <gitster@pobox•com>
To: Jeff King <peff@peff•net>
Cc: Johannes Schindelin <johannes.schindelin@gmx•de>,
Paul Tan <pyokagan@gmail•com>,
git@vger•kernel.org, Stefan Beller <sbeller@google•com>
Subject: Re: debugging git tests, was: Re: [PATCH v4 2/8] t5520: test no merge candidates cases
Date: Mon, 18 May 2015 12:35:37 -0700 [thread overview]
Message-ID: <xmqqd21xbrw6.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <20150518185554.GB11463@peff.net> (Jeff King's message of "Mon, 18 May 2015 14:55:54 -0400")
Jeff King <peff@peff•net> 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
next prev parent reply other threads:[~2015-05-18 19:35 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-18 13:32 [PATCH v4 0/8] Improve git-pull test coverage Paul Tan
2015-05-18 13:32 ` [PATCH v4 1/8] t5520: prevent field splitting in content comparisons Paul Tan
2015-05-18 18:07 ` Junio C Hamano
2015-05-18 13:32 ` [PATCH v4 2/8] t5520: test no merge candidates cases Paul Tan
2015-05-18 15:08 ` Johannes Schindelin
2015-05-18 17:46 ` Junio C Hamano
2015-05-18 18:55 ` debugging git tests, was: " Jeff King
2015-05-18 19:35 ` Junio C Hamano [this message]
2015-05-19 13:29 ` Johannes Schindelin
2015-06-05 10:44 ` Jeff King
2015-05-18 13:32 ` [PATCH v4 3/8] t5520: test for failure if index has unresolved entries Paul Tan
2015-05-18 15:13 ` Johannes Schindelin
2015-05-21 8:15 ` Paul Tan
2015-05-18 13:32 ` [PATCH v4 4/8] t5520: test work tree fast-forward when fetch updates head Paul Tan
2015-05-18 15:22 ` Johannes Schindelin
2015-05-18 13:32 ` [PATCH v4 5/8] t5520: test --rebase with multiple branches Paul Tan
2015-05-18 13:32 ` [PATCH v4 6/8] t5520: test --rebase failure on unborn branch with index Paul Tan
2015-05-18 18:00 ` Stefan Beller
2015-05-21 8:51 ` Paul Tan
2015-05-18 13:32 ` [PATCH v4 7/8] t5521: test --dry-run does not make any changes Paul Tan
2015-05-18 13:32 ` [PATCH v4 8/8] t5520: check reflog action in fast-forward merge Paul Tan
2015-05-18 15:20 ` Johannes Schindelin
2015-05-21 8:07 ` Paul Tan
2015-05-21 17:29 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqd21xbrw6.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=johannes.schindelin@gmx$(echo .)de \
--cc=peff@peff$(echo .)net \
--cc=pyokagan@gmail$(echo .)com \
--cc=sbeller@google$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox