Re: [PATCH] t: fix "that that" typos in test comments
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Mar 2, 2026, 18:46 UTC
- Message-ID
- <xmqqfr6i133u.fsf@gitster.g>
- In-Reply-To
- <20260302164521.79148-1-r.siddharth.shrimali@gmail.com>
Siddharth Shrimali <r.siddharth.shrimali@gmail.com> writes:
Show 11 quoted lines
> 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,
While the original in this hunk clearly has unwanted "that" there and removing it is unambiguously the single right thing to do here, ...
> # 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.
... this does not fall into the same category, does it? The phrasing may be a bit awkward, but it is not factually or gramatically wrong per-se.
I think the next one also falls into the same category as this one. In fact, referring to that one arbitrary path chosen in the previous step as "that arbitrary path" (i.e., the original) may convey the intent more cleanly than the updated one "the arbitrary path".
Show 13 quoted lines
> 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