On Wed, Aug 5, 2020 at 3:11 AM Bin Meng bmeng.cn@gmail.com wrote:
On Tue, Aug 4, 2020 at 10:58 PM Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 04.08.20 15:15, Bin Meng wrote:
On Tue, Aug 4, 2020 at 7:02 PM Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 04.08.20 03:46, Bin Meng wrote:
On Tue, Aug 4, 2020 at 5:26 AM Heinrich Schuchardt xypron.glpk@gmx.de wrote:
...
Fixes: 191636e44898 ("riscv: Introduce SPL_SMP Kconfig option for U-Boot SPL")
This should be on the same line
The rule of thumb is one tag == one line. Otherwise it breaks a lot of scripting here and there. The reason why is that actually Unix tools are not designed (yes, I know it's possible to do in some cases) to handle multi-line processing (like multi-line grep). So, 100% Fixes should be one line. Also this is applicable to URLs.
Commit messages should not exceed 75 characters. See scripts/checkpatch.pl:
True, for normal commit messages.
WARN("COMMIT_LOG_LONG_LINE", "Possible unwrapped commit description (prefer a maximum 75 chars per line)\n" . $herecurr);
This warning is bogus. Fix your tools.
But this Fixes tag is special. I suspect 2 lines will break some scripts that is handling this "Fixes" tag.
Precisely!
checkpatch.pl and patchstream.py are the only U-Boot scripts containing the string "Fixes".
- checkpatch.pl does not complain.
- I don't use patman. So I don't care if it has a bug.
You don't but maintainers tell you what to do. And yes, tools sometimes wrong or false positive, feel free to complain about them.
We already have patches like this by other developers and nobody complained:
IIRC, last time Andy raised the same concern.
Andy, would you share some examples or best practices?
dcdea292d9f3 4fb2264b2848 00160cf32e6e
So why should I worry?
I hope above clarifies. And it's generally a weak argument to point to bad examples in the past.