[oe] update hook for git to check push commit message

Frans Meulenbroeks fransmeulenbroeks at gmail.com
Thu Jan 28 22:01:01 UTC 2010


2010/1/28 Phil Blundell <philb at gnu.org>:
> On Thu, 2010-01-28 at 12:00 -0800, Khem Raj wrote:
>> Attached is a small hook for updates that are pushed into repo.
>> Right now it only checks the first line of the commit and expects
>> module: summary
>
> I'm not really in favour of applying the commit message policy quite
> that harshly.  The wiki page that you linked to doesn't really seem to
> support this kind of check: the actual guidance it gives about checkin
> messages is:
>
> * Have a clear commit message (example):
>    - The first line of commit is a summary of the changes.
>    - The first line should start with the name of the recipe the change affects.

What if a commit is not about a recipe but e.g. about a class file
and what if a commit changes multiple recipes ? (i had this one once
when eliminating lots of perl native recipes replacing them with
BBCLASSEXTEND="native")
This was a pain editing already. I think I would have stopped doing it
if I had to commit each individual patch

>    - The rest of the message should give more details on the change as appropriate.
>    - Mention the affected bug numbers if appropriate.
>    - Give credit where credit is due. If you commit someone else's work more or
>      less verbatim, you should use git commit --author $mail-of-author. If pulling
>      changes from somewhere like Poky or OpenMoko there is no problem with that
>      but mention where the changes came from.
>    - Include a Signed-off-by: line indicating the change has valid certificate
>      of origin as per the Linux kernel

Not sure if we can influence the template that you get with git commit
but I would surely like to learn if one way or another I can add a
Signed-off-by lne automatically

>
> ... which is nowhere near as prescriptive as the rule that you seem to
> be implementing in your script.  Also, the wiki page has an explicit
> statement that "[these] rules are not hard fast rules", which would
> suggest that even such guidance as it does provide is not intended to be
> taken too dogmatically.
>
> Personally I think that the current situation of the TSC applying
> pressure to those people who seem to be chronically unable to write
> suitable checkin comments is a perfectly fine way of solving the
> problem.

Agree

FM

>
> On a technical level, I think you could probably do without the sed
> subprocess, and "summary = rev.split(1)" doesn't look quite right
> either.
>
> p.
>
>
> p.
>
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>




More information about the Openembedded-devel mailing list