git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Sebastian Staudt <koraktor@gmail.com>
Cc: Git Mailing List <git@vger.kernel.org>,
	Junio C Hamano <gitster@pobox.com>,
	Duy Nguyen <pclouds@gmail.com>
Subject: Re: [PATCH v3 1/3] Add tests for describe with --work-tree
Date: Tue, 29 Jan 2019 08:00:32 -0500	[thread overview]
Message-ID: <20190129130031.GA22211@sigill.intra.peff.net> (raw)
In-Reply-To: <20190129051859.12830-1-koraktor@gmail.com>

On Tue, Jan 29, 2019 at 06:18:57AM +0100, Sebastian Staudt wrote:

> The dirty ones are already passing, but just because describe is comparing
> with the wrong working tree.
> 
> Signed-off-by: Sebastian Staudt <koraktor@gmail.com>
> ---
>  t/t6120-describe.sh | 33 +++++++++++++++++++++++++++++++++
>  1 file changed, 33 insertions(+)
> 
> diff --git a/t/t6120-describe.sh b/t/t6120-describe.sh
> index d639d94696..c863c4f600 100755
> --- a/t/t6120-describe.sh
> +++ b/t/t6120-describe.sh
> @@ -145,14 +145,38 @@ check_describe A-* HEAD
>  
>  check_describe "A-*[0-9a-f]" --dirty
>  
> +test_expect_success 'describe --dirty with --work-tree' "

This should be marked as test_expect_failure, I think, because it does
not yet pass (and then flipped s/failure/success/ in the next patch).

> +	(
> +		cd '$TEST_DIRECTORY' &&
> +		git --git-dir '$TRASH_DIRECTORY/.git' --work-tree '$TRASH_DIRECTORY' describe --dirty >'$TRASH_DIRECTORY/out'
> +	) &&

The quoting you've done here is unusual for our test suite, and not
quite as robust. You've put the whole test snippet into double-quotes,
which means that $TRASH_DIRECTORY, etc, will be expanded before we eval
the code.

By putting single-quotes around $TRASH_DIRECTORY, that makes it work
when the path contains a space. But it would fail if somebody's
filesystem path contains a single-quote.

The usual style is to put the whole snippet into single-quotes, and then
double-quote as appropriate within it. Like:

  test_expect_failure 'describe --dirty with --work-tree' '
	(
		cd "$TEST_DIRECTORY" &&
		git --git-dir "$TRASH_DIRECTORY/.git" ...etc

Those variables will be expanded when test_expect_failure eval's the
snippet.

> +	grep 'A-\d\+-g[0-9a-f]\+' '$TRASH_DIRECTORY/out'

Using "\d" isn't portable.

This regex is pretty broad. What are we checking here? If I understand
the previous discussion, we just care that it doesn't have "dirty" in
it, right? I don't think this regex does that, because it doesn't anchor
the end of string.

If that's indeed what we're checking, then an easier check is perhaps:

  ! grep dirty ...

As a side note, you can also shorten your references to "out" by
referring to it from the trash directory itself. I.e.:

  (
	cd "$TEST_DIRECTORY" &&
	git --git-dir="$TRASH_DIRECTORY/.git" --work-tree "$TRASH_DIRECTORY" \
	  describe --dirty
  ) >out &&
  ! grep dirty out

Same thing, but IMHO a little easier to read.

>  check_describe "A-*[0-9a-f]-dirty" --dirty
>  
> +test_expect_success 'describe --dirty with --work-tree' "
> [...]

Same comments apply to the other blocks you added.

Other than those mechanical things, though, what the tests are actually
trying to do seems quite reasonable to me.

-Peff

  parent reply	other threads:[~2019-01-29 13:00 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-29  5:18 [PATCH v3 1/3] Add tests for describe with --work-tree Sebastian Staudt
2019-01-29  5:18 ` [PATCH v3 2/3] Setup working tree in describe Sebastian Staudt
2019-01-29 13:11   ` Jeff King
2019-01-29 17:39     ` Junio C Hamano
2019-01-29 20:53     ` Eric Sunshine
2019-01-29 22:35       ` Jeff King
2019-01-30 10:31         ` Sebastian Staudt
2019-01-30 12:44           ` Jeff King
2019-01-29  5:18 ` [PATCH v3 3/3] Add test for describe with a bare repository Sebastian Staudt
2019-01-29 13:12   ` Jeff King
2019-01-30 10:23     ` Sebastian Staudt
2019-01-29 13:00 ` Jeff King [this message]
2019-01-29 17:47   ` [PATCH v3 1/3] Add tests for describe with --work-tree Junio C Hamano
2019-01-30 10:23     ` Sebastian Staudt
2019-01-30 12:43       ` Jeff King

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=20190129130031.GA22211@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=koraktor@gmail.com \
    --cc=pclouds@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).