Versions Compared

Old Version 39

changes.mady.by.user George Joseph

Saved on

compared with

New Version 40

changes.mady.by.user Sean Bright

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Misc. formatting and switch recommended wrap columns to 72
Section
Column

Commit Messages

A commit message serves to notify others of the changes made to the Asterisk source code, both in a historical sense and in the present. Commit messages are incredibly important to the continued success of the Asterisk project. Developers maintaining the Asterisk project in the future will often only have your commit message to guide them in why a particular change was made. For non-developers, archives containing commit messages may be used when searching for fixes to a particular bug. Be sure that the information contained in your message will help them out.

Warning
titleFollow These Guidelines

Commit messages are part of your code change. Committing code with a poorly written commit message creates a maintenance problem for everyone in the Asterisk project.

As such, your commit message is part of your code review. Code submissions with a poorly written commit message or one that fails to use the appropriate headers listed on this page will not be accepted.

This page describes the expected format for commit messages used when submitting code to the Asterisk project.   See Gerrit Usage for more information about pushing your commit for review.

Column
Panel
titleOn This Page

 

Table of Contents
maxLevel2

...

Commit messages should be wrapped at 80 72 columns.

Note that for trivial commits, such as fixes for spelling mistakes, the verbose description may not be necessary.

...

Note

If you do not reference an issue when you submit a review the review tool will remind you that you should. While it is not currently required to include an issue in the commit message it is highly preferred.

 

Issue Referencing

To have a commit noted in an issue and to also close the issue, simply referencing the issue is sufficient:

...

If the patch being committed was written by the person doing the commit ,  and is not available to reference as an upload to the issue , there is  is no need to include something like "fixed by me" , as that will be the default assumption when a specific patch is not referenced.

...

No Format
core/db: Fix DBDelTree error codes for AMI, CLI and AGI.

The AMI DBDelTree command will return Success/Key tree deleted
successfully even if the given key does not exist. The CLI command
'database deltree' had a similar problem, but was saved because it
actually responded with '0 database entries removed'. AGI had a
slightly different error, where it would return success if the database
was unavailable.

This came from confusion about the ast_db_deltree retval, which is -1
in the event of a database error, or number of entries deleted
(including 0 for deleting nothing).

* Changed some poorly named res variables to num_deleted
* Specified specific errors when calling ast_db_deltree (database
unavailable  unavailable vs. entry not found vs. success)
* Fixed similar bug in AGI database deltree, where 'Database
  unavailable'   results in successful result

ASTERISK-967
Reported by: John Bigelow
Tested by: John Bigelow