Re: [PATCH v3 0/4] Optimization batch 12: miscellaneous unthemed stuff

From: Elijah Newren <newren@gmail.com>
Date: Jun 4, 2021, 16:30 UTC
Message-ID: <CABPp-BHbDY+y6mJb3QgYeLaqbPM8qphOGmoZXsO31094ZWgwrA@mail.gmail.com>
In-Reply-To: <CABPp-BEsiw-E9_TGUDaGEkhQHNqLH48=ZTu7yXX7XqRaM2JdOQ@mail.gmail.com>

On Fri, Jun 4, 2021 at 8:48 AM Elijah Newren <newren@gmail.com> wrote:

>
> On Fri, Jun 4, 2021 at 6:11 AM Derrick Stolee <stolee@gmail.com> wrote:
> >
> > On 6/4/2021 12:39 AM, Elijah Newren via GitGitGadget wrote:

Show 18 quoted lines

> > >  * Added Stolee's Acked-by
> > ...
> > >  1:  c4a0f6a9510c ! 1:  f63ffc2a7c22 merge-ort: replace string_list_df_name_compare with faster alternative
> > >      @@ Commit message
> > >               just-one-mega:   500.3  ms ±  3.8  ms   480.1  ms ±  3.9  ms
> > >
> > >           Signed-off-by: Elijah Newren <newren@gmail.com>
> > >      +    Acked-by: Derrick Stolee <dstolee@microsoft.com>
> >
> > I believe the sign-off should always be the last thing in
> > the message. Perhaps Junio is willing to fix this without a
> > re-roll?
>
> Interesting, this is the first I've ever heard of such a requirement,
> and I've submitted patches this way numerous times and have seen
> others do it.  A quick search through git.git history says there are
> 5133 commits that place such trailers before the author's
> Signed-off-by, and 1175 that place them after.  While the former is

Sorry, there was a bug in my script, found while running it on the linux kernel (where the Signed-off-by stuff came from) to see if it was different. The corrected numbers are:

Author Signed-off-by comes after all non-Signed-off-by trailers: 2990 non-Signed-off-by trailers follow the Author's Signed-off-by line: 3069

So, this suggests it's even less of a rule. For those curious, the Linux kernel has these numbers:

Author Signed-off-by comes after all non-Signed-off-by trailers: 83530 non-Signed-off-by trailers follow the Author's Signed-off-by line: 199778

> ...
> So, if "Signed-off-by should come last" is a rule, then neither
> existing practice nor our documentation seem to cover it.  I'll assume
> it's not a rule for now.