From: Jeff King <peff@peff.net>
To: Brian Gesiak <modocache@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] t3200-branch: test setting branch as own upstream
Date: Thu, 6 Mar 2014 16:00:26 -0500 [thread overview]
Message-ID: <20140306210025.GD29659@sigill.intra.peff.net> (raw)
In-Reply-To: <1394004715-18776-1-git-send-email-modocache@gmail.com>
On Wed, Mar 05, 2014 at 04:31:55PM +0900, Brian Gesiak wrote:
> No test asserts that "git branch -u refs/heads/my-branch my-branch"
> emits a warning. Add a test that does so.
>
> Signed-off-by: Brian Gesiak <modocache@gmail.com>
Thanks, this looks good. Two minor points that may or may not be worth
addressing:
> +test_expect_success '--set-upstream-to shows warning if used to set branch as own upstream' '
> + git branch --set-upstream-to refs/heads/my13 my13 2>actual &&
> + cat >expected <<EOF &&
> +warning: Not setting branch my13 as its own upstream.
> +EOF
If you spell the EOF marker as:
cat >expect <<-\EOF
then:
1. The shell does not interpolate the contents (it does not matter
here, but it is a good habit to be in, so we typically do it unless
there is a need to interpolate).
2. Using <<- will strip leading tabs, so the content can be indented
properly along with the rest of the test.
> + test_i18ncmp expected actual &&
> + test_must_fail git config branch.my13.remote &&
> + test_must_fail git config branch.my13.merge
I think we could tighten these to:
test_expect_code 1 git config branch.my13.remote
to eliminate a false-positive success on other config errors. It's
highly improbable for it to ever matter, though (and it looks like we
are not so careful in most other places that call "git config" looking
for a missing entry, either).
-Peff
next prev parent reply other threads:[~2014-03-06 21:00 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-28 6:41 [PATCH v2 1/2] t3200-branch: test setting branch as own upstream Brian Gesiak
2014-03-04 23:56 ` Junio C Hamano
2014-03-05 7:31 ` [PATCH] " Brian Gesiak
2014-03-06 21:00 ` Jeff King [this message]
2014-03-06 21:53 ` 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=20140306210025.GD29659@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=modocache@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).