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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jun 04, 2021 at 08:48:21AM -0700, Elijah Newren wrote:

> > >           Signed-off-by: Elijah Newren <newren@xxxxxxxxx>
> > >      +    Acked-by: Derrick Stolee <dstolee@xxxxxxxxxxxxx>
> >
> > 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
> clearly more common, and some of the latter could have been Junio
> adding trailers while applying the patches, there still seem like
> plenty of counter-examples suggesting that there is no rule here.

I don't think there's a hard rule here. The usual advice (which I also
didn't find documented from a quick grep, but hopefully is kind of
intuitive) is that trailers should be chronological.

So if you picked up a patch from person X who signed off, then you
modified and signed off the result, then Junio signed off after
applying, we'd expect that chain of custody to be represented by reading
top to bottom. And that's what happens if you use "am -s", "commit -s",
etc.

Whether "Acked-by" happens after the author signs off or not is
debatable. Obviously it happens after the version of the patch that is
sent out. But if you re-send with an Acked-by, is the signoff your one
from before that happened first, or a new one that happened as you sent
out the patch? Perhaps a question for the philosophers. ;)

Anyway, I think it is perfectly fine either way (as your numbers
indicate).

-Peff



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux