From: Junio C Hamano <gitster@pobox.com>
To: Paul Tan <pyokagan@gmail.com>
Cc: Michael Blume <blume.mike@gmail.com>,
Git List <git@vger.kernel.org>,
Stefan Beller <sbeller@google.com>,
Johannes Schindelin <johannes.schindelin@gmx.de>
Subject: Re: [PATCH v3 1/9] t5520: fixup file contents comparisons
Date: Fri, 15 May 2015 11:37:55 -0700 [thread overview]
Message-ID: <xmqq7fs9hekc.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <CACRoPnSbekLANNiGOyxN70TCUd1c=wcrU_6Gfew5pp5EBpSEsA@mail.gmail.com> (Paul Tan's message of "Fri, 15 May 2015 19:41:39 +0800")
Paul Tan <pyokagan@gmail.com> writes:
> Hi Junio,
>
> On Fri, May 15, 2015 at 1:44 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Change that 'verbose test' line to
>>
>> verbose test 1 = $(find .git/rebase-apply -name "000*" | wc -l)
>>
>> i.e. losing the double-quotes around $().
>
> Noted and fixed. Interesting quirk though :-).
>
>> By the way, thanks for a fine demonstration that the 'verbose test'
>> is not very useful.
>>
>> This output
>>
>>> command failed: 'test' '1' '=' ' 1'
>
> Personally, I find that the quoting provided by "verbose" helps make
> it clear that it's a whitespace issue, which might be a bit harder to
> spot with the output of set -x I think.
To be fair, yes, because of the leading SP in the RHS, I immediately
knew that this was a "wc -l" from that without running the test one
more time with "-i -v -x". The "rev-parse --sq-quote" did help.
Without the --sq-quote trick, i.e. "command failed: test 1 = 1",
would actually make the debugger suspect that there would be a
quoting issue anyway, so it is not a very big deal, though.
In any case, that "test 1 = 1" (with or without quoting) helped only
because I had to deal with "wc -l" issues in the past. Without
telling how that ' 1' ended up compared with '1' by showing "wc -l"
on that 'command failed:' line, it wouldn't have helped much if the
debugger were not me.
> Other than that, I'm also convinced that "verbose" doesn't really
> offer much. Will remove in the re-roll.
Just to avoid misunderstanding, please do not remove 'verbose '
blindly without thinking while doing so, as you already did 1/3 of
the necessary job to make things better.
You might have noticed, while adding them, there were something
common that we currently do with a bare 'test' only because we
haven't identified common needs. As I already said, it may be that
we often try to see a file has a known single line content (I didn't
check if that were the case; I am just giving you an example) and
only because there is no ready-made test_file_contents helper to be
used, the current tests say
test expected_string = "$(cat file)"
And if that were the case, it is a good thing to have a new helper
like this
test_file_contents () {
if test "$(cat "$1")" != "$2"
then
echo "Contents of file '$1' is not '$2'"
false
fi
}
in t/test-lib-functions.sh and convert them to say
test_file_contents file expected_string
That would be an improvement (and that is the remaining 2/3 ;-).
Thanks.
next prev parent reply other threads:[~2015-05-15 18:38 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-13 9:08 [PATCH v3 0/9] Improve git-pull test coverage Paul Tan
2015-05-13 9:08 ` [PATCH v3 1/9] t5520: fixup file contents comparisons Paul Tan
2015-05-13 14:01 ` Junio C Hamano
2015-05-13 14:42 ` Junio C Hamano
2015-05-14 17:29 ` Michael Blume
2015-05-14 17:44 ` Junio C Hamano
2015-05-15 11:41 ` Paul Tan
2015-05-15 18:37 ` Junio C Hamano [this message]
2015-05-15 19:22 ` Junio C Hamano
2015-05-16 13:49 ` Paul Tan
2015-05-16 18:57 ` Junio C Hamano
2015-05-16 23:32 ` Junio C Hamano
2015-05-17 7:47 ` Paul Tan
2015-05-13 9:08 ` [PATCH v3 2/9] t5520: ensure origin refs are updated Paul Tan
2015-05-13 14:27 ` Junio C Hamano
2015-05-18 13:09 ` Paul Tan
2015-05-13 9:08 ` [PATCH v3 3/9] t5520: test no merge candidates cases Paul Tan
2015-05-13 9:08 ` [PATCH v3 4/9] t5520: test for failure if index has unresolved entries Paul Tan
2015-05-13 9:32 ` Matthieu Moy
2015-05-15 8:25 ` Paul Tan
2015-05-13 9:08 ` [PATCH v3 5/9] t5520: test work tree fast-forward when fetch updates head Paul Tan
2015-05-13 9:08 ` [PATCH v3 6/9] t5520: test --rebase with multiple branches Paul Tan
2015-05-13 9:08 ` [PATCH v3 7/9] t5520: test --rebase failure on unborn branch with index Paul Tan
2015-05-13 9:08 ` [PATCH v3 8/9] t5521: test --dry-run does not make any changes Paul Tan
2015-05-13 9:08 ` [PATCH v3 9/9] t5520: check reflog action in fast-forward merge Paul Tan
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=xmqq7fs9hekc.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=blume.mike@gmail.com \
--cc=git@vger.kernel.org \
--cc=johannes.schindelin@gmx.de \
--cc=pyokagan@gmail.com \
--cc=sbeller@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.