Re: [oe] [OE-core] Git commit process question.
On Wed, Apr 3, 2019 at 7:41 AM Tom Rini wrote: > > On Wed, Apr 03, 2019 at 11:30:39AM +0100, Burton, Ross wrote: > > On Tue, 2 Apr 2019 at 20:46, Tom Rini wrote: > > > > The kernel does not have "upgrade foo to the latest upstream version" > > > > commits. > > > > > > > > With the Automatic Upgrade Helper this is a semi-automatic task, and > > > > most of the time there is no specific motivation other than upgrading > > > > to the latest upstream version. > > > > > > But since that's just filling in a template the body can also be a > > > template perhaps with useful AUH data (run at ... by ... ?) ? > > > > Apart from making the commit message longer what does this achieve? > > The commit already has a timestamp and author. > > It's an etiquette thing. Subject+Sign-off+Empty body is bad form. AUH > updates are a form of "trivial update" that every project has. "Update > $X from version $Y to $Z" is what a human would normally put. It's > weird looking at git log of nothing but subject+signed-off-by. I'm not > going to object further on this point, but I don't get it. if the content of subject is being repeated in body then I would prefer an empty body redundant information in commits should be avoided since it can create impression that body does not have useful information and skip reading it. We should strive to make commits concise and useful. -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] Git commit process question.
On Wed, Apr 03, 2019 at 11:30:39AM +0100, Burton, Ross wrote: > On Tue, 2 Apr 2019 at 20:46, Tom Rini wrote: > > > The kernel does not have "upgrade foo to the latest upstream version" > > > commits. > > > > > > With the Automatic Upgrade Helper this is a semi-automatic task, and > > > most of the time there is no specific motivation other than upgrading > > > to the latest upstream version. > > > > But since that's just filling in a template the body can also be a > > template perhaps with useful AUH data (run at ... by ... ?) ? > > Apart from making the commit message longer what does this achieve? > The commit already has a timestamp and author. It's an etiquette thing. Subject+Sign-off+Empty body is bad form. AUH updates are a form of "trivial update" that every project has. "Update $X from version $Y to $Z" is what a human would normally put. It's weird looking at git log of nothing but subject+signed-off-by. I'm not going to object further on this point, but I don't get it. -- Tom signature.asc Description: PGP signature -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] Git commit process question.
Just to make clear, the AUH workflow does require the maintainer to sign off and edit a commit message via 'git commit -s --reset-author --amend' for every commit, so AUH does not get in the way of useful commit messages. Alex On Wed, 3 Apr 2019 at 12:31, Burton, Ross wrote: > > On Tue, 2 Apr 2019 at 20:46, Tom Rini wrote: > > > The kernel does not have "upgrade foo to the latest upstream version" > > > commits. > > > > > > With the Automatic Upgrade Helper this is a semi-automatic task, and > > > most of the time there is no specific motivation other than upgrading > > > to the latest upstream version. > > > > But since that's just filling in a template the body can also be a > > template perhaps with useful AUH data (run at ... by ... ?) ? > > Apart from making the commit message longer what does this achieve? > The commit already has a timestamp and author. > > Ross > -- > ___ > Openembedded-core mailing list > openembedded-c...@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] Git commit process question.
On Tue, 2 Apr 2019 at 20:46, Tom Rini wrote: > > The kernel does not have "upgrade foo to the latest upstream version" > > commits. > > > > With the Automatic Upgrade Helper this is a semi-automatic task, and > > most of the time there is no specific motivation other than upgrading > > to the latest upstream version. > > But since that's just filling in a template the body can also be a > template perhaps with useful AUH data (run at ... by ... ?) ? Apart from making the commit message longer what does this achieve? The commit already has a timestamp and author. Ross -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] Git commit process question.
On Tue, Apr 02, 2019 at 03:46:14PM -0400, Tom Rini wrote: > On Tue, Apr 02, 2019 at 09:51:21AM +0300, Adrian Bunk wrote: > > On Mon, Apr 01, 2019 at 04:20:41PM -0700, 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 > > > > > > 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. > > >... > > > > The kernel does not have "upgrade foo to the latest upstream version" > > commits. > > > > With the Automatic Upgrade Helper this is a semi-automatic task, and > > most of the time there is no specific motivation other than upgrading > > to the latest upstream version. > > But since that's just filling in a template the body can also be a > template perhaps with useful AUH data (run at ... by ... ?) ? That would be more trivial than useful. And so far noone has stated any actual problem that would be solved by adding such a new requirement. > Tom cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] Git commit process question.
On Wed, Apr 3, 2019 at 7:45 AM Tom Rini wrote: > > On Tue, Apr 02, 2019 at 02:24:51PM -0700, akuster808 wrote: > > > > > > On 4/2/19 12:47 PM, Tom Rini wrote: > > > On Tue, Apr 02, 2019 at 04:45:16AM +, Jon Mason wrote: > > >> On Tue, Apr 2, 2019 at 6:41 AM Mark Hatle > > >> 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. > > 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. > > Note that I'm not talking about a hook, I'm talking about what's part of > my CI process. And when something pops up there is when I grab the > patch in question and push back on the submitter. Exactly! I do the same things for the Linux stuff I own. I'll do a git-am, then redir the output and publicly shame them. Public shaming is a vastly underrated method of behavior modification. Thanks, Jon > > -- > Tom -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] Git commit process question.
On Tue, Apr 02, 2019 at 02:24:51PM -0700, akuster808 wrote: > > > On 4/2/19 12:47 PM, Tom Rini wrote: > > On Tue, Apr 02, 2019 at 04:45:16AM +, Jon Mason wrote: > >> On Tue, Apr 2, 2019 at 6:41 AM Mark Hatle 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. > 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. Note that I'm not talking about a hook, I'm talking about what's part of my CI process. And when something pops up there is when I grab the patch in question and push back on the submitter. -- Tom signature.asc Description: PGP signature -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] Git commit process question.
signature.asc Description: OpenPGP digital signature -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] Git commit process question.
On 4/2/19 12:46 PM, Tom Rini wrote: > On Tue, Apr 02, 2019 at 09:51:21AM +0300, Adrian Bunk wrote: >> On Mon, Apr 01, 2019 at 04:20:41PM -0700, 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 >>> >>> 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. >>> ... >> The kernel does not have "upgrade foo to the latest upstream version" >> commits. >> >> With the Automatic Upgrade Helper this is a semi-automatic task, and >> most of the time there is no specific motivation other than upgrading >> to the latest upstream version. > But since that's just filling in a template the body can also be a > template perhaps with useful AUH data (run at ... by ... ?) ?.. Maybe, if someone want to enhance the AUH. - armin > -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] Git commit process question.
On Tue, Apr 02, 2019 at 04:45:16AM +, Jon Mason wrote: > On Tue, Apr 2, 2019 at 6:41 AM Mark Hatle 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-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] Git commit process question.
On Tue, Apr 02, 2019 at 09:51:21AM +0300, Adrian Bunk wrote: > On Mon, Apr 01, 2019 at 04:20:41PM -0700, 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 > > > > 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. > >... > > The kernel does not have "upgrade foo to the latest upstream version" commits. > > With the Automatic Upgrade Helper this is a semi-automatic task, and > most of the time there is no specific motivation other than upgrading > to the latest upstream version. But since that's just filling in a template the body can also be a template perhaps with useful AUH data (run at ... by ... ?) ? -- Tom signature.asc Description: PGP signature -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] Git commit process question.
On Mon, Apr 01, 2019 at 04:20:41PM -0700, 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 > > 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. >... The kernel does not have "upgrade foo to the latest upstream version" commits. With the Automatic Upgrade Helper this is a semi-automatic task, and most of the time there is no specific motivation other than upgrading to the latest upstream version. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] Git commit process question.
On Tue, Apr 2, 2019 at 6:41 AM Mark Hatle 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 - Perhaps something similar can be added to check for this. Thanks, Jon > > > >> Cheers, > >> > >> Richard > >> > > > > > > -- > ___ > Openembedded-core mailing list > openembedded-c...@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] Git commit process question.
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 > >> Cheers, >> >> Richard >> > > -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] Git commit process question.
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 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 > > Cheers, > > Richard > -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] Git commit process question.
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? Cheers, Richard -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
