Re: Tabs in commit messages - de-tabify option in strbuf_stripspace()?

On Tue, Mar 15, 2016 at 5:23 PM, Stefan Beller <sbeller@google.com> wrote:

So in the kernel repo, I just randomly looked for tabs that show this problem, and take for example commit ff9a9b4c4334b53b52ee9279f30bd5dd92ea9bdd.

You can see how the original lined up, by doing

    git show --pretty=email ff9a9b4c4334

because the email format doesn't indent the commit message. But if you do just

    git show ff9a9b4c4334

and get the usual indentation, you'll see things not line up at all.

In case you don't want to bother with the kernel repo, here's what it looks like:

email format:

--- snip snip 8< --- A microbenchmark calling an invalid syscall number 10 million times in a row speeds up an additional 30% over the numbers with just the previous patches, for a total speedup of about 40% over 4.4 and 4.5-rc1.

Run times for the microbenchmark:

 4.4                            3.8 seconds
 4.5-rc1                        3.7 seconds
 4.5-rc1 + first patch          3.3 seconds
 4.5-rc1 + first 3 patches      3.1 seconds
 4.5-rc1 + all patches          2.3 seconds

A non-NOHZ_FULL cpu (not the housekeeping CPU):

 all kernels                    1.86 seconds
--- snip snip 8< ---

Normal "git show" format:

--- snip snip 8< ---
    A microbenchmark calling an invalid syscall number 10 million
    times in a row speeds up an additional 30% over the numbers
    with just the previous patches, for a total speedup of about
    40% over 4.4 and 4.5-rc1.

    Run times for the microbenchmark:

     4.4                                3.8 seconds
     4.5-rc1                    3.7 seconds
     4.5-rc1 + first patch              3.3 seconds
     4.5-rc1 + first 3 patches  3.1 seconds
     4.5-rc1 + all patches              2.3 seconds

    A non-NOHZ_FULL cpu (not the housekeeping CPU):

     all kernels                        1.86 seconds
--- snip snip 8< ---

which hopefully clarifies.

In the above case, it really isn't very annoying. It's just slightly ugly. In some other cases, it can get quite hard to see what's up, but the ones that come through me I actually tend to try to edit, so many of them have been corrected.

For other examples (again, in the kernel), look at 19b2c30d3cce, or 0dc8c730c98a.

                Linus