Re: [PATCH 4/4] cherry-pick: Add `--empty` for more robust redundant commit handling

Brian Lyles <brianmlyles@gmail.com> writes:

I got curious and took a look at files that has hits with "lines that end with SP or HT":

    $ git grep -l -e '[  ]$'

There are some that can be cleaned up, but many of them are intentional.

For example, CODE_OF_CONDUCT.md has these two (shown with $$$) I think can be removed without breaking markdown:

    Community Impact Guidelines were inspired by $$$
    [Mozilla's code of conduct enforcement ladder][Mozilla CoC].

    For answers to common questions about this code of conduct, see the FAQ at
    [https://www.contributor-covenant.org/faq][FAQ]. Translations are available $$$
    at [https://www.contributor-covenant.org/translations][translations].

The one in Documentation/user-manual.txt is on borderline. They appear in a sample output from a command the user is typing (again, $$$ shows where the SP at the end of line is):

    diff --git a/init-db.c b/init-db.c
    index 65898fa..b002dc6 100644
    --- a/init-db.c
    +++ b/init-db.c
    @@ -7,7 +7,7 @@
     $$$
     int main(int argc, char **argv)
    ...

As its purpose is to show human readers what they see in their terminal should _look_ like, we _could_ do without the single space on these otherwise empty lines, which denotes an empty line that hasn't changed in the diff output. But it would no longer match byte-for-byte with what we are trying to illustrate.

There are many hits from the above grep in t/t[0-9][0-9][0-9][0-9]/ directories; these are canonical/expected output used in tests and the spaces at the end of these lines are expected.