-
Notifications
You must be signed in to change notification settings - Fork 374
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Git Commit Format #585
Comments
I will no write too much commit so this is clearly a decision on your side but I'm not sure making the description mandatory is a good idea. Sometime there is nothing much to say than just the summary. |
I know Zephyr has this rule. While sometimes worked around (e.g. zephyrproject-rtos/zephyr@22a82bc), it seems to me that such a rule encourages greatly to come up with helpful commit messages. 72 characters are most often not enough to describe the motivation behind a commit. For example, most of the last 20 commit messages in https://github.com/zephyrproject-rtos/zephyr/commits/zephyr-v2.5.0 makes me feel like I have a shot at understand the commits intention thanks to the additional information in the body. |
From personal experience I can say, that being forced to write a description is sometimes annoying. However it forces yourself to think again about the commit. Also the workaround mentioned by @rettichschnidi works for small changes. I would support such a rule. |
Naming and explaining is usually the hardest part, but very important. I'm for (although I will regret it :) |
This is a fairly default configuration, which, among other stuff, checks for the subject line being 72 or less characters as required by the Eclipse project handbook. In addition, it checks for the Signed-off-by tag. This simplifies to detect missing signatures even before creating a PR. Please note: gitlint 0.15.1 is required to detect the tags created by Git. Signed-off-by: Reto Schneider <code@reto-schneider.ch>
…aaay too long commit message subject This is a fairly default configuration, which, among other stuff, checks for the subject line being 72 or less characters as required by the Eclipse project handbook. In addition, it checks for the Signed-off-by tag. This simplifies to detect missing signatures even before creating a PR. Please note: gitlint 0.15.1 is required to detect the tags created by Git. Signed-off-by: Reto Schneider <code@reto-schneider.ch>
…aaay too long commit message subject This is a fairly default configuration, which, among other stuff, checks for the subject line being 72 or less characters as required by the Eclipse project handbook. In addition, it checks for the Signed-off-by tag. This simplifies to detect missing signatures even before creating a PR when being executed locally. Please note: gitlint 0.15.1 is required to detect the tags created by Git. Signed-off-by: Reto Schneider <code@reto-schneider.ch>
This is a fairly default configuration, which, among other stuff, checks for the subject line being 72 or less characters as required by the Eclipse project handbook. In addition, it checks for the Signed-off-by tag. This simplifies to detect missing signatures even before creating a PR when being executed locally. Please note: gitlint 0.15.1 is required to detect the tags created by Git. Signed-off-by: Reto Schneider <code@reto-schneider.ch>
This is a fairly default configuration, which, among other stuff, checks for the subject line being 72 or less characters as required by the Eclipse project handbook. In addition, it checks for the Signed-off-by tag. This simplifies to detect missing signatures even before creating a PR when being executed locally. Please note: - gitlint 0.15.1 is required to detect the tags created by Git. - Using the gitlint-ignore tag in a commit message allows to suppress gitlint findings for a specific commit. Signed-off-by: Reto Schneider <code@reto-schneider.ch>
This is a fairly default configuration, which, among other stuff, checks for the subject line being 72 or less characters as required by the Eclipse project handbook. In addition, it checks for the Signed-off-by tag. This simplifies to detect missing signatures even before creating a PR when being executed locally. Please note: - gitlint 0.15.1 is required to detect the tags created by Git. - Using the gitlint-ignore tag in a commit message allows to suppress gitlint findings for a specific commit. Signed-off-by: Reto Schneider <code@reto-schneider.ch>
…aaaay too long subject
… subjectttttttttttttt
This is a fairly default configuration, which, among other stuff, checks for the subject line being 72 or less characters as required by the Eclipse project handbook. Please note: - Using the gitlint-ignore tag in a commit message allows to suppress gitlint findings for a specific commit.
This is a fairly default configuration, which, among other stuff, checks for the subject line being 72 or less characters as required by the Eclipse project handbook. Additional rules: - Enforce at least 20 characters in the commit body - Disallow the word "fixup" in the title messages. Intended to prevent accidents like d31d026. Please note: - Using the gitlint-ignore tag in a commit message allows to suppress gitlint findings for a specific commit.
This is a fairly default configuration, which, among other stuff, checks for the subject line being 72 or less characters as required by the Eclipse project handbook. Non-default rules: - Enforce at least 20 characters in the commit body - Disallow the word "fixup" in the title messages. Intended to prevent accidents like d31d026. In case any of those rules get in the way, use the "gitlint-ignore" tag in the commit message to suppress gitlint findings for this specific commit. To configure a rule permanently, adapt .gitlint.
This is a fairly default configuration, which, among other stuff, checks for the subject line being 72 or less characters as required by the Eclipse project handbook. Non-default rules: - Enforce at least 20 characters in the commit body - Disallow the word "fixup" in the title messages. Intended to prevent accidents like d31d026. In case any of those rules get in the way, use the "gitlint-ignore" tag in the commit message to suppress gitlint findings for this specific commit. To configure a rule permanently, adapt .gitlint. The GitHub Action runs only on PRs, not after each push. The idea is to prevent annoyance when working on code, using WIP or other non-compliant commit messages.
After all those force-pushes, I think the PR #590 is now in a good shape and ready to be reviewed. |
This is a fairly default configuration, which, among other stuff, checks for the subject line being 72 or less characters as required by the Eclipse project handbook. Non-default rules: - Enforce at least 20 characters in the commit body - Disallow the word "fixup" in the title messages. Intended to prevent accidents like d31d026. In case any of those rules get in the way, use the "gitlint-ignore" tag in the commit message to suppress gitlint findings for this specific commit. To configure a rule permanently, adapt .gitlint. The GitHub Action runs only on PRs, not after each push. The idea is to prevent annoyance when working on code, using WIP or other non-compliant commit messages.
This is a fairly default configuration, which, among other stuff, checks for the subject line being 72 or less characters as required by the Eclipse project handbook. Non-default rules: - Enforce at least 20 characters in the commit body - Disallow the word "fixup" in the title messages. Intended to prevent accidents like d31d026. In case any of those rules get in the way, use the "gitlint-ignore" tag in the commit message to suppress gitlint findings for this specific commit. To configure a rule permanently, adapt .gitlint. The GitHub Action runs only on PRs, not after each push. The idea is to prevent annoyance when working on code, using WIP or other non-compliant commit messages.
This is a fairly default configuration, which, among other stuff, checks for the subject line being 72 or less characters as required by the Eclipse project handbook. Non-default rules: - Enforce at least 20 characters in the commit body - Disallow the word "fixup" in the title messages. Intended to prevent accidents like d31d026. In case any of those rules get in the way, use the "gitlint-ignore" tag in the commit message to suppress gitlint findings for this specific commit. To configure a rule permanently, adapt .gitlint. The GitHub Action runs only on PRs, not after each push. The idea is to prevent annoyance when working on code, using WIP or other non-compliant commit messages.
Just merged PR #590, which covers this issue. |
This was used for debugging purposes and is no longer needed.
This workflow does not have gitlint installed, and does not need it. Therefore it should not try to invoke it. This error could get introduced because SonarCloud scan are running only on master for now. See 866e505 for details.
This was used for debugging purposes and is no longer needed.
This workflow does not have gitlint installed, and does not need it. Therefore it should not try to invoke it. This error could get introduced because SonarCloud scan are running only on master for now. See 866e505 for details.
The Eclipse Foundation Project Handbook specifies how a Git commit must look like in order to be acceptable.
The following rule is mandatory, could be checked automatically but is currently now:
The following rule is not mandatory ("should"), but when implementing the above as a checked in CI, I'd like to enforce it too:
The text was updated successfully, but these errors were encountered: