Ramkumar Ramachandra wrote:
I've
never really found the outputs from earlier tests enlightening.
If the test suite would automatically use set -x when appropriate
so output for each command was preceded by the command being run,
that
Junio C Hamano wrote:
But the output from passing -v before the test that breaks is not
very useful for two reasons.
I sometimes checkout the Good branch in a different worktree, compare
the output/ state of the passing test with the failing one. I've
never really found the outputs from
A couple of tests execute 'git rebase' with GIT_TRACE set to 1, but
this trace output is not used anywhere. Remove it, since it is not
relevant to what we are testing.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
t/t3400-rebase.sh | 4 ++--
1 file changed, 2 insertions(+), 2
Ramkumar Ramachandra artag...@gmail.com writes:
A couple of tests execute 'git rebase' with GIT_TRACE set to 1, but
this trace output is not used anywhere.
Isn't it shown in t4300-*.sh -v output to help the debugger?
relevant to what we are testing.
Signed-off-by: Ramkumar Ramachandra
Junio C Hamano wrote:
Ramkumar Ramachandra artag...@gmail.com writes:
A couple of tests execute 'git rebase' with GIT_TRACE set to 1, but
this trace output is not used anywhere.
Isn't it shown in t4300-*.sh -v output to help the debugger?
Um, but why the GIT_TRACE in just these two places?
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
Ramkumar Ramachandra artag...@gmail.com writes:
A couple of tests execute 'git rebase' with GIT_TRACE set to 1, but
this trace output is not used anywhere.
Isn't it shown in t4300-*.sh -v output to help the debugger?
Junio C Hamano wrote:
Perhaps because this is a test about rebase and a typical debugger
does not want to trace other git things while debugging this?
Okay, let's drop this 4-part series: it's too minor.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
Perhaps because this is a test about rebase and a typical debugger
does not want to trace other git things while debugging this?
Okay, let's drop this 4-part series: it's too minor.
Why throw the baby with bathwater?
To
Junio C Hamano wrote:
To me, most of them look like responses to valid issues, and that
holds true even for [PATCH 1/4]. Even though your response may have
been an incorrect one, the issue that triggered the response is
still valid---the setting of these variables without explanation
invites
Ramkumar Ramachandra wrote:
I just comment out the test_expect_success and close-quote, and put a
test_done after it. I would never advocate this GIT_TRACE thing
anywhere, because I want to put GIT_TRACE=1 (and possibly other
modifications) where I want it. Locally.
On that note, I'd really
Ramkumar Ramachandra wrote:
Quite frankly, I think -v is completely useless; who likes to scroll
through pages of terminal output?
I use -v -i together quite frequently when debugging. I also use
-v automatically to debug test failures when tests are invoked
automatically on machines I do not
Jonathan Nieder wrote:
I use -v -i together quite frequently when debugging. I also use
-v automatically to debug test failures when tests are invoked
automatically on machines I do not have access to.
Yeah, it makes sense on remote machines. I just found out about -i,
and the -v -i
Ramkumar Ramachandra wrote:
Can we do better by not printing the -v
output of the passing tests though?
Not for my use. The output from comprable tests before is often
useful for comparison. I wouldn't be against such an option for
people who want it, though.
Jonathan Nieder jrnie...@gmail.com writes:
Ramkumar Ramachandra wrote:
Can we do better by not printing the -v
output of the passing tests though?
Not for my use. The output from comprable tests before is often
useful for comparison.
Perhaps.
But the output
14 matches
Mail list logo
