On Tue, Apr 02, 2019 at 04:45:16AM +0000, Jon Mason wrote: > On Tue, Apr 2, 2019 at 6:41 AM Mark Hatle <mark.ha...@windriver.com> wrote: > > > > On 4/1/19 6:20 PM, akuster808 wrote: > > > > > > > > > On 4/1/19 4:02 PM, Richard Purdie wrote: > > >> On Mon, 2019-04-01 at 15:33 -0700, akuster808 wrote: > > >>> Hello, > > >>> > > >>> I have noticed a large number of git commits with no header > > >>> information being accepted. > > >> Can you be more specific about what "no header information" means? You > > >> mean a shortlog and no full log message? > > > Commits with just a "subject" and signoff. No additional information > > > > If you can convey the reason for the change in just the subject, that is > > acceptable.. but there is -always- supposed to be a signed-off-by line > > according > > to our guidelines. > > > > So if you see this, I think we need to step back and figure out where and > > why > > it's happening and get it resolved in the future. > > > > (Places I've seen in the past were one-off mistakes and clearly that -- so > > it > > wasn't anything that we needed to work on a correction.) > > > > --Mark > > > > > We tend to reference back to how the kernel does things. > > > > > > https://www.kernel.org/doc/html/latest/process/submitting-patches.html > > > These two sections in particular. > > > > > > > > > 2) Describe your changes > > > > > > Describe your problem. Whether your patch is a one-line bug fix or 5000 > > > lines of > > > a new feature, there must be an underlying problem that motivated you to > > > do this > > > work. Convince the reviewer that there is a problem worth fixing and that > > > it > > > makes sense for them to read past the first paragraph. > > > > > > > > > along with this section. > > > > > > > > > 14) The canonical patch format > > > > > > This section describes how the patch itself should be formatted. Note > > > that, if > > > you have your patches stored in a |git| repository, proper patch > > > formatting can > > > be had with |git format-patch|. The tools cannot create the necessary > > > text, > > > though, so read the instructions below anyway. > > > > > > The canonical patch subject line is: > > > > > > Subject: [PATCH 001/123] subsystem: summary phrase > > > > > > The canonical patch message body contains the following: > > > > > > * A |from| line specifying the patch author, followed by an empty > > > line > > > (only needed if the person sending the patch is not the author). > > > * The body of the explanation, line wrapped at 75 columns, which > > > will be > > > copied to the permanent changelog to describe this patch. > > > * An empty line. > > > * The |Signed-off-by:| lines, described above, which will also go > > > in the > > > changelog. > > > * A marker line containing simply |---|. > > > * Any additional comments not suitable for the changelog. > > > * The actual patch (|diff| output). > > > > > > > > > - Armin > > There are existing git hooks that can be used to detect and fail to > merge patches like this. For Linux, I have the following in > .git/hooks/pre-commit > #!/bin/sh > exec git diff --cached | scripts/checkpatch.pl -
FWIW, over in U-Boot land I do: ./scripts/checkpatch.pl -q --git origin/master.. as part of checking things prior to pushing to master. -- Tom
signature.asc
Description: PGP signature
-- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
