Re: [PATCH v2 1/2] t: don't spuriously close and reopen quotes

["Martin Ågren" <martin.agren@gmail.com>]

Hi Eric,

Thanks for having a look.

On Thu, 6 Aug 2020 at 22:26, Eric Sunshine <sunshine@sunshineco.com> wrote:
>
> On Thu, Aug 6, 2020 at 4:09 PM Martin Ågren <martin.agren@gmail.com> wrote:
> > diff --git a/t/t4200-rerere.sh b/t/t4200-rerere.sh
> > @@ -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.

[1] https://lore.kernel.org/git/20100805112837.GL13779@burratino/>

> > diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh
> > @@ -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.

Thanks
Martin