All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Hansen <rhansen@bbn.com>
To: Eric Sunshine <sunshine@sunshineco.com>
Cc: Git List <git@vger.kernel.org>,
	Junio C Hamano <gitster@pobox.com>, Jeff King <peff@peff.net>
Subject: Re: [PATCH v3] peel_onion(): add support for <rev>^{tag}
Date: Tue, 03 Sep 2013 15:39:41 -0400	[thread overview]
Message-ID: <52263AFD.3060308@bbn.com> (raw)
In-Reply-To: <CAPig+cRQP5CGz_1ckf5Qr6HcB+OvWHNPtGQ8RxWdqTZK0fRo2w@mail.gmail.com>

On 2013-09-03 15:03, Eric Sunshine wrote:
> On Tue, Sep 3, 2013 at 1:37 PM, Richard Hansen <rhansen@bbn.com> wrote:
>> diff --git a/t/t1511-rev-parse-caret.sh b/t/t1511-rev-parse-caret.sh
>> index eaefc77..5771cbd 100755
>> --- a/t/t1511-rev-parse-caret.sh
>> +++ b/t/t1511-rev-parse-caret.sh
>> @@ -54,6 +61,26 @@ test_expect_success 'ref^{tree}' '
>>         test_must_fail git rev-parse blob-tag^{tree}
>>  '
>>
>> +test_expect_success 'ref^{tag}' '
>> +       echo $BLOB_TAG_SHA1 >expected &&
>> +       git rev-parse --verify blob-tag^{tag} >actual &&
>> +       test_cmp expected actual &&
>> +       echo $TREE_TAG_SHA1 >expected &&
>> +       git rev-parse --verify tree-tag^{tag} >actual &&
>> +       test_cmp expected actual &&
>> +       echo $COMMIT_TAG_SHA1 >expected &&
>> +       git rev-parse --verify commit-tag^{tag} >actual &&
>> +       test_cmp expected actual &&
>> +       echo $TAG_TAG_SHA1 >expected &&
>> +       git rev-parse --verify tag-tag^{tag} >actual &&
>> +       test_cmp expected actual &&
>> +       test_must_fail git rev-parse --verify $BLOB_SHA1^{tag} &&
>> +       test_must_fail git rev-parse --verify $TREE_SHA1^{tag} &&
>> +       test_must_fail git rev-parse --verify $COMMIT_SHA1^{tag} &&
>> +       test_must_fail git rev-parse --verify rev^{tag} &&
>> +       true
>> +'
> 
> The unnecessary trailing "&& true" is unusual. Such form is not used
> elsewhere in this file, or in any script in the test suite.

True.  I can take it out, and while I'm at it simplify the test case to
what Peff suggested.

I'm in the habit of using that idiom because (1) I won't break things if
I forget to add/remove '&&' when I add/remove lines in a future commit,
and (2) it simplifies conflict resolution if two commits touch the same
list of stuff.

-Richard

      reply	other threads:[~2013-09-03 19:39 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-03 17:37 [PATCH v3] peel_onion(): add support for <rev>^{tag} Richard Hansen
2013-09-03 17:46 ` Jeff King
2013-09-03 19:03 ` Eric Sunshine
2013-09-03 19:39   ` Richard Hansen [this message]

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=52263AFD.3060308@bbn.com \
    --to=rhansen@bbn.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    --cc=sunshine@sunshineco.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.