<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<br>
<div class="moz-cite-prefix">On 4/2/19 12:47 PM, Tom Rini wrote:<br>
</div>
<blockquote type="cite"
cite="mid:20190402194738.GZ4664@bill-the-cat">
<pre class="moz-quote-pre" wrap="">On Tue, Apr 02, 2019 at 04:45:16AM +0000, Jon Mason wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">On Tue, Apr 2, 2019 at 6:41 AM Mark Hatle <a class="moz-txt-link-rfc2396E" href="mailto:mark.hatle@windriver.com"><mark.hatle@windriver.com></a> wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
On 4/1/19 6:20 PM, akuster808 wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
On 4/1/19 4:02 PM, Richard Purdie wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">On Mon, 2019-04-01 at 15:33 -0700, akuster808 wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Hello,
I have noticed a large number of git commits with no header
information being accepted.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">Can you be more specific about what "no header information" means? You
mean a shortlog and no full log message?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">Commits with just a "subject" and signoff. No additional information
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">We tend to reference back to how the kernel does things.
<a class="moz-txt-link-freetext" href="https://www.kernel.org/doc/html/latest/process/submitting-patches.html">https://www.kernel.org/doc/html/latest/process/submitting-patches.html</a>
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
</pre>
</blockquote>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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 -
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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.</pre>
</blockquote>
Having hooks is fine but after the fact. It puts the burden back on
the Layer maintainer to resolve. If we think more info is better, it
needs to happen at time of change submittal.<br>
<br>
- armin<br>
<blockquote type="cite"
cite="mid:20190402194738.GZ4664@bill-the-cat">
<pre class="moz-quote-pre" wrap="">
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
</blockquote>
<br>
</body>
</html>