From: Markus Elfring <Markus.Elfring@web.de>
To: Wang YanQing <udknight@gmail.com>, kernel-janitors@vger.kernel.org
Cc: linux-kernel@vger.kernel.org,
Alexei Starovoitov <alexei.starovoitov@gmail.com>,
Andy Whitcroft <apw@canonical.com>, Joe Perches <joe@perches.com>,
Matteo Croce <mcroce@redhat.com>
Subject: Re: [v3] checkpatch: add dedicated checker for 'Fixes:' tag
Date: Wed, 29 Apr 2020 17:18:52 +0200 [thread overview]
Message-ID: <f1234e16-eca2-e2af-c5a6-92f47fcbd98d@web.de> (raw)
In-Reply-To: <20200428161831.GB30042@udknight>
>> * Do you try to extend the existing software analysis approach “GIT_COMMIT_ID”?
>>
>> * Would you like to avoid the development of duplicate Perl code?
>
> Fixes: lines don't need to have a "commit" prefix before the commit id, the description
> in normal commit id could across multiple lines, and we don't need to consider the
> $commit_log_possible_stack_dump for 'Fixes:' tag line.
It can be helpful to know such differences.
> I mean it will make the GIT_COMMIT_ID code become harder to read and maintain.
This view depends on some factors.
* How many data processing can be shared for your software extension?
* Do you get any further development ideas from a previous suggestion
by Joe Perches according to the discussion topic “linux-next:
Fixes tag needs some work in the tip tree”?
https://lkml.org/lkml/2019/1/17/966
https://lore.kernel.org/lkml/40bfc40958fca6e2cc9b86101153aa0715fac4f7.camel@perches.com/
Regards,
Markus
next prev parent reply other threads:[~2020-04-29 15:19 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-28 2:02 [PATCH v3] checkpatch: add dedicated checker for 'Fixes:' tag Wang YanQing
2020-04-28 6:21 ` Markus Elfring
2020-04-28 14:06 ` Wang YanQing
2020-04-28 14:54 ` [v3] " Markus Elfring
2020-04-28 10:52 ` [PATCH v3] " Markus Elfring
2020-04-28 16:18 ` Wang YanQing
2020-04-29 15:18 ` Markus Elfring [this message]
2020-04-28 16:10 ` Joe Perches
2020-04-28 23:17 ` Joe Perches
2020-04-29 6:45 ` [v3] " Markus Elfring
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f1234e16-eca2-e2af-c5a6-92f47fcbd98d@web.de \
--to=markus.elfring@web.de \
--cc=alexei.starovoitov@gmail.com \
--cc=apw@canonical.com \
--cc=joe@perches.com \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mcroce@redhat.com \
--cc=udknight@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox