list mirror (unofficial, one of many)
 help / color / mirror / Atom feed
From: "Martin Ågren" <>
To: Eric Sunshine <>
Cc: Git List <>,
	Junio C Hamano <>,
	Chris Torek <>
Subject: Re: [PATCH v2 1/2] t: don't spuriously close and reopen quotes
Date: Fri, 7 Aug 2020 10:45:29 +0200
Message-ID: <> (raw)
In-Reply-To: <>

Hi Eric,

Thanks for having a look.

On Thu, 6 Aug 2020 at 22:26, Eric Sunshine <> wrote:
> On Thu, Aug 6, 2020 at 4:09 PM Martin Ågren <> wrote:
> > diff --git a/t/ b/t/
> > @@ -364,7 +364,7 @@ test_expect_success 'set up an unresolved merge' '
> >         fifth=$(git rev-parse fifth) &&
> > -       echo "$fifth            branch 'fifth' of ." |
> > +       echo "$fifth            branch fifth of ." |
> >         git fmt-merge-msg >msg &&
> This one is a bit weird. It really seems as if the intent was to quote
> the word "fifth" in the merge message, so dropping the quotes
> altogether seems wrong. However, the file 'msg' is never even
> consulted in this test (or any other test), so is this just "dead
> code" (including the leading 'fifth=' assignment which also is
> otherwise unused outside the 'echo')?

Huh, good catch. The tests showed up in v2 of the patch [1] and there's
not enough context in the archives to tell whether something was partly
removed from an earlier "v1.5" or partly added but not all the way.

We expect to fail the merge -- and we do, and not because of this msg
thing -- and then we look around a little, but we don't resolve the
merge and make a commit. And from what I can tell, there wouldn't be
much point in making a commit. So I should be able to safely drop this
"dead code" entirely.


> > diff --git a/t/ b/t/
> > @@ -213,7 +213,7 @@ test_expect_success 'fetch tags when there is no tags' '
> >  test_expect_success 'fetch following tags' '
> >         cd "$D" &&
> > -       git tag -a -m 'annotated' anno HEAD &&
> > +       git tag -a -m "annotated" anno HEAD &&
> There are a fair number of these quoted single-token arguments
> containing no special characters which don't actually need to be
> quoted at all, so an alternative would be simply to drop the quotes
> altogether, making the commands less syntactically noisy. However,
> that might be outside the intended scope of this change.

FWIW, I find something like `git foo -m "message"` a lot more
intuitive/reasonable than, e.g., `git foo "HEAD"` to signal that here's
a message that could in principle have whitespace, even if this one
doesn't. For all of these, I tried to follow the surrounding style. For
example in t9401, where we do `echo "hi"`. We certainly don't need the
quotes there, but t9401 is very consistent on this and I didn't want to
muddy that unnecessarily.

If we say that "don't use quotes if you don't need to" is a reasonable
thing to strive for, I can drop these in a reroll. I think I'll be
injecting a patch anyway for the "msg" you pointed out in t4200, so I
can certainly tweak this patch to be a bit more aggressive in dropping
unnecessary quotes.


  reply	other threads:[~2020-08-07  8:45 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-01 22:06 [PATCH] t1450: fix quoting of NUL byte when corrupting pack Martin Ågren
2020-08-02  0:45 ` Junio C Hamano
2020-08-02 14:30   ` Martin Ågren
2020-08-02 17:22     ` Eric Sunshine
2020-08-06 20:08     ` [PATCH v2 0/2] t: don't spuriously close and reopen quotes Martin Ågren
2020-08-06 20:08       ` [PATCH v2 1/2] " Martin Ågren
2020-08-06 20:26         ` Eric Sunshine
2020-08-07  8:45           ` Martin Ågren [this message]
2020-08-07 16:17             ` Eric Sunshine
2020-08-07 17:16               ` Junio C Hamano
2020-08-06 20:08       ` [PATCH v2 2/2] t4104: modernize and simplify quoting Martin Ågren
2020-08-02  1:00 ` [PATCH] t1450: fix quoting of NUL byte when corrupting pack Chris Torek
2020-08-02  1:02   ` Chris Torek
2020-08-02 14:35     ` Martin Ågren
2020-08-02 16:20       ` Chris Torek
2020-08-02 17:57         ` 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:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link list mirror (unofficial, one of many)

This inbox may be cloned and mirrored by anyone:

	git clone --mirror
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 git git/ \
	public-inbox-index git

Example config snippet for mirrors.
Newsgroups are available over NNTP:
 note: .onion URLs require Tor:

code repositories for the project(s) associated with this inbox:

AGPL code for this site: git clone