Re: [PATCH] t: fix "that that" typos in test comments

>
> Several test scripts in the t/ directory contained "that that"
> typos in their comments. Updated these scripts to use "it", "the", or
> a single "that" where appropriate.
>
> Signed-off-by: Siddharth Shrimali <r.siddharth.shrimali@gmail.com>
> ---
>  t/lib-unicode-nfc-nfd.sh          | 2 +-
>  t/t0019-json-writer.sh            | 2 +-
>  t/t6416-recursive-corner-cases.sh | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/t/lib-unicode-nfc-nfd.sh b/t/lib-unicode-nfc-nfd.sh
> index aed0a4dd44..201ab9b24c 100755
> --- a/t/lib-unicode-nfc-nfd.sh
> +++ b/t/lib-unicode-nfc-nfd.sh
> @@ -75,7 +75,7 @@ test_lazy_prereq UNICODE_NFD_PRESERVED '
>  #
>  # Note that I've used the canonical ordering of the
>  # combining characters.  It is also possible to
> -# swap them.  My testing shows that that non-standard
> +# swap them.  My testing shows that non-standard
>  # ordering also causes a collision in mkdir.  However,
>  # the resulting names don't draw correctly on the
>  # terminal (implying that the on-disk format also has
> diff --git a/t/t0019-json-writer.sh b/t/t0019-json-writer.sh
> index 3a4e1cc7e3..0d30cd36d5 100755
> --- a/t/t0019-json-writer.sh
> +++ b/t/t0019-json-writer.sh
> @@ -290,7 +290,7 @@ test_lazy_prereq PERLJSON '
>  '
>
>  # As a sanity check, ask Perl to parse our generated JSON and recursively
> -# dump the resulting data in sorted order.  Confirm that that matches our
> +# dump the resulting data in sorted order.  Confirm that it matches our
>  # expectations.
>  test_expect_success PERLJSON 'parse JSON using Perl' '
>         cat >expect <<-\EOF &&
> diff --git a/t/t6416-recursive-corner-cases.sh b/t/t6416-recursive-corner-cases.sh
> index ed20de8ea2..63de0fc6cb 100755
> --- a/t/t6416-recursive-corner-cases.sh
> +++ b/t/t6416-recursive-corner-cases.sh
> @@ -775,7 +775,7 @@ test_expect_failure 'merge of D2 & E4 merges a2s & reports conflict for a/file'
>  # it feels sound to say "B and C do not agree what the final pathname
>  # should be, but we know this content was derived from the common A:a so we
>  # use one path whose name is arbitrary in the virtual merge base X between
> -# D and E" and then further let the rename detection to notice that that
> +# D and E" and then further let the rename detection to notice that the
>  # arbitrary path gets renamed between X-D to "newname" and X-E also to
>  # "newname" to resolve it as both sides renaming it to the same new
>  # name. It is akin to what we do at the content level, i.e. "B and C do not
> --
> 2.51.2
>