git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Eric Sunshine <sunshine@sunshineco.com>
To: Fabian Stelzer <fs@gigacodes.de>
Cc: Git List <git@vger.kernel.org>, Jeff King <peff@peff.net>
Subject: Re: [PATCH 12/19] tests: fix broken &&-chains in `{...}` groups
Date: Sat, 11 Dec 2021 02:32:19 -0500	[thread overview]
Message-ID: <CAPig+cRDKM3E5ZEV-A8Ze7pzDnM+s=xs0ioW_qXoM3yYfu7jSw@mail.gmail.com> (raw)
In-Reply-To: <20211210093827.a5s5mby3if5f7a4u@fs>

On Fri, Dec 10, 2021 at 4:38 AM Fabian Stelzer <fs@gigacodes.de> wrote:
> On 09.12.2021 00:11, Eric Sunshine wrote:
> >Fix broken &&-chains in `{...}` groups in order to reduce the number of
> >possible lurking bugs.
> >       {
> >-          echo "*.t filter=rot13"
> >+          echo "*.t filter=rot13" &&
> >           echo "*.i ident"
> >       } >.gitattributes &&
> >       {
> >-              echo "expanded-keywords ident"
> >+              echo "expanded-keywords ident" &&
> >               echo "expanded-keywords-crlf ident text eol=crlf"
> >       } >>.gitattributes &&
> >
>
> Wouldn't some of these be better off as heredocs as well?
> There are a couple more below. I personally don't much mind either way but
> since you changed quite a few in an earlier commit why not these?

It's been months since I made these changes, but I think there were at
least a couple reasons for not converting these to here-docs. First,
in these cases, there were only one or two missing `&&` per block. Had
I bulk converted them to here-docs, it would have made for a much more
noisy patch, which would have taxed reviewers more, and
reviewer-fatigue is a real concern when crafting a lengthy patch
series like this one. In the "here-doc conversion" patch, on the other
hand, many of those cases involved a significant number of missing
`&&`; often every line was missing `&&`. So, the changes in that patch
was going to be very noisy anyhow, whether I added missing `&&` or
converted to here-docs.

Second...

> >       {
> >               echoid insert 444 1 2 3 4 5 a b c d e &&
> >-              echoid contains 44 441 440 444 4440 4444
> >+              echoid contains 44 441 440 444 4440 4444 &&
> >               echo clear
> >       } | test-tool oidtree >actual &&

... there are a number of cases like this which look like they could
easily be converted to here-doc, but in fact `echoid` is a function
call, so a here-doc wouldn't work. Also...

> >       {
> >               echo $(git rev-parse refs/tags/A) refs/tags/A &&
> >-              echo $(git rev-parse refs/tags/A^0) "refs/tags/A^{}"
> >+              echo $(git rev-parse refs/tags/A^0) "refs/tags/A^{}" &&
> >               echo $(git rev-parse refs/tags/C) refs/tags/C
> >       } >expect &&

... this sort of thing could certainly become a here-doc because
$(...) will work in a here-doc, but when there is a preponderance of
this sort of `{ echo && ... }` block in the test script, it would feel
inconsistent to convert a few of them to here-docs.

  reply	other threads:[~2021-12-11  7:32 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-09  5:10 [PATCH 00/19] tests: fix broken &&-chains & abort loops on error Eric Sunshine
2021-12-09  5:10 ` [PATCH 01/19] t/lib-pager: use sane_unset() to avoid breaking &&-chain Eric Sunshine
2021-12-09  5:10 ` [PATCH 02/19] t1010: fix unnoticed failure on Windows Eric Sunshine
2021-12-09 16:27   ` Elijah Newren
2021-12-09 16:45     ` Eric Sunshine
2021-12-09  5:10 ` [PATCH 03/19] t1020: avoid aborting entire test script when one test fails Eric Sunshine
2021-12-09  5:11 ` [PATCH 04/19] t4202: clarify intent by creating expected content less cleverly Eric Sunshine
2021-12-10  9:09   ` Jeff King
2021-12-09  5:11 ` [PATCH 05/19] t5516: drop unnecessary subshell and command invocation Eric Sunshine
2021-12-10  9:10   ` Jeff King
2021-12-09  5:11 ` [PATCH 06/19] t6300: make `%(raw:size) --shell` test more robust Eric Sunshine
2021-12-10  9:14   ` Jeff King
2021-12-09  5:11 ` [PATCH 07/19] t9107: use shell parameter expansion to avoid breaking &&-chain Eric Sunshine
2021-12-09  5:11 ` [PATCH 08/19] tests: simplify construction of large blocks of text Eric Sunshine
2021-12-09  5:11 ` [PATCH 09/19] tests: use test_write_lines() to generate line-oriented output Eric Sunshine
2021-12-10  9:22   ` Jeff King
2021-12-11  6:59     ` Eric Sunshine
2021-12-09  5:11 ` [PATCH 10/19] tests: fix broken &&-chains in compound statements Eric Sunshine
2021-12-09  5:11 ` [PATCH 11/19] tests: fix broken &&-chains in `$(...)` command substitutions Eric Sunshine
2021-12-09 16:44   ` Elijah Newren
2021-12-09 16:53     ` Eric Sunshine
2021-12-09 16:57       ` Elijah Newren
2021-12-10  9:27       ` Jeff King
2021-12-09  5:11 ` [PATCH 12/19] tests: fix broken &&-chains in `{...}` groups Eric Sunshine
2021-12-10  9:29   ` Jeff King
2021-12-11  7:14     ` Eric Sunshine
2021-12-10  9:38   ` Fabian Stelzer
2021-12-11  7:32     ` Eric Sunshine [this message]
2021-12-09  5:11 ` [PATCH 13/19] tests: apply modern idiom for signaling test failure Eric Sunshine
2021-12-10  9:32   ` Jeff King
2021-12-11  7:47     ` Eric Sunshine
2021-12-09  5:11 ` [PATCH 14/19] tests: apply modern idiom for exiting loop upon failure Eric Sunshine
2021-12-10  9:36   ` Jeff King
2021-12-09  5:11 ` [PATCH 15/19] tests: simplify by dropping unnecessary `for` loops Eric Sunshine
2021-12-09 16:50   ` Elijah Newren
2021-12-09  5:11 ` [PATCH 16/19] t0000-t3999: detect and signal failure within loop Eric Sunshine
2021-12-09  5:11 ` [PATCH 17/19] t4000-t4999: " Eric Sunshine
2021-12-10  9:53   ` Fabian Stelzer
2021-12-11  8:06     ` Eric Sunshine
2021-12-09  5:11 ` [PATCH 18/19] t5000-t5999: " Eric Sunshine
2021-12-09  5:11 ` [PATCH 19/19] t6000-t9999: " Eric Sunshine
2021-12-09 17:02 ` [PATCH 00/19] tests: fix broken &&-chains & abort loops on error Elijah Newren
2021-12-09 19:17   ` Eric Sunshine
2021-12-10  9:38     ` Jeff King
2021-12-10  9:57       ` Fabian Stelzer
2021-12-11  8:16         ` Eric Sunshine
2021-12-11  9:58 ` [PATCH v1.1 2/19] t1010: fix unnoticed failure on Windows Eric Sunshine

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to='CAPig+cRDKM3E5ZEV-A8Ze7pzDnM+s=xs0ioW_qXoM3yYfu7jSw@mail.gmail.com' \
    --to=sunshine@sunshineco.com \
    --cc=fs@gigacodes.de \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).