public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed

From: Junio C Hamano <gitster@pobox•com>
To: Paul Tan <pyokagan@gmail•com>
Cc: git@vger•kernel.org, Stefan Beller <sbeller@google•com>,
	Johannes Schindelin <johannes.schindelin@gmx•de>
Subject: Re: [PATCH v4 1/8] t5520: prevent field splitting in content comparisons
Date: Mon, 18 May 2015 11:07:26 -0700	[thread overview]
Message-ID: <xmqqa8x1dajl.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <1431955978-17890-2-git-send-email-pyokagan@gmail.com> (Paul Tan's message of "Mon, 18 May 2015 21:32:51 +0800")

Paul Tan <pyokagan@gmail•com> writes:

> Many tests in t5520 used the following to test the contents of files:
>
> 	test `cat file` = expected
>
> or
>
> 	test $(cat file) = expected
>
> These 2 forms, however, will be affected by field splitting and,
> depending on the value of $IFS, may be split into multiple arguments,
> making the test fail in mysterious ways.
>
> Replace the above 2 forms with:
>
> 	test "$(cat file)" = expected
>
> as quoting the command substitution will prevent field splitting.
>
> Signed-off-by: Paul Tan <pyokagan@gmail•com>
> ---
> * Removed use of "verbose"
>
> * The use of "wc -l" is not quoted, as the output of "wc -l" on a Mac contains
>   leading whitespace. See [1].
>
> [1] http://thread.gmane.org/gmane.comp.version-control.git/268950/focus=269052
>
>  t/t5520-pull.sh | 70 ++++++++++++++++++++++++++++-----------------------------
>  1 file changed, 35 insertions(+), 35 deletions(-)

Overall the series was a pleasant read.

Some common patterns (my mind is still continuing the verbose_test
topic) I noticed were

 (1) comparing output from two rev-parse output for object names. We
     have test_cmp_rev we can use for better readability (but its
     implementaiton may want to be updated not to contaminate the
     working tree unnecessarily). e.g

	test "$(git rev-parse HEAD^)" = "$(git rev-parse copy)"
     => test_cmp_rev HEAD^ copy
 
 (2) checking contents of a file, either from a working tree, from
     the index or from a rev, with a fixed short string.

	test_contents () {
                case "$1" in
                *:*)	git cat-file blob "$1" ;;
                *)	cat "$1" ;;
                esac >actual &&
		printf "%s" "$2" >expect &&
		if ! cmp -s expect actual
                then
			echo "Unexpected contents in '$1'"
			test_cmp expect actual
		else
			: good ;
		fi
	}

     or something.


I think it is a good idea *not* to address these patterns within
this series, and have people come back to them _after_ the series
settles, to reduce code churn and unnecessary conflicts.

Thanks.

next prev parent reply	other threads:[~2015-05-18 18:07 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 [this message]
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
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=xmqqa8x1dajl.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox$(echo .)com \
    --cc=git@vger$(echo .)kernel.org \
    --cc=johannes.schindelin@gmx$(echo .)de \
    --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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox