On Mon, Mar 4, 2013 at 7:06 AM, Quim Gil qgil@wikimedia.org wrote:
fwiw this is not a discussion about Gerrit features but about git commit and code contribution good practices in general. There is plenty of literature out there.
I also prefer it in the header. The bug report is the best description :)
A bug report is supposed to describe a problem while the title of a commit message is supposed to describe the solution implemented.
Plus you are limited to 50 chars. The bug number will take 5, that leaves you less than 45.
Plus quite frequently a bug is fixed through more than one commit, and still you are supposed to explain in each commit message what you are doing in that commit.
I like to know about the problem before the solution implemented, that saves me some time to think what solutions could be possible. But that doesn't mean it always have to be in the header. It matters from the point of view, looking like a bug fixer you are more concerned with bug numbers while other people are concerned about what is implemented.
But what I find more important is see the bug numbers in the Gerrit 'view', its easy to find the change for a particular bug being solved. Having a separate column (as Erik suggested) for that would be the best solution :)
Is it not possible for Gerrit to search if its in the header?
Is this helpful?
status:merged message:<yourString>
http://stackoverflow.com/**questions/14409413/searching-** gerrit-by-commit-messagehttp://stackoverflow.com/questions/14409413/searching-gerrit-by-commit-message
Tools should be coded around people. Not the other way around.
Agree. A 100% human readable commit message title describing what a commit does feels more human than "Fixes Bug 12345" + <truncated bug description>
Is there another software project that uses the summary line
in a similar way to MediaWiki?
That was the best question of this thread. I have done some research, and the guidelines I found mentioning the inclusion of bug numbers in commit messages pointed all to a specific bug line after the commit description and an empty line - which is in line with our guidelines. Gerrit and other Git tools understand that line as metadata and you can do good things with it (as we are on our way of doing between Gerrit and Bugzilla):
OpenStack Git Commit Good Practice https://wiki.openstack.org/**wiki/GitCommitMessageshttps://wiki.openstack.org/wiki/GitCommitMessages
Chromium - Contributing code http://www.chromium.org/**developers/contributing-codehttp://www.chromium.org/developers/contributing-code
Qt - Introduction to Gerrit http://qt-project.org/wiki/**Gerrit-Introductionhttp://qt-project.org/wiki/Gerrit-Introduction
GNOME - a guide to writing git commit messages http://blogs.gnome.org/danni/**2011/10/25/a-guide-to-writing-** git-commit-messages/http://blogs.gnome.org/danni/2011/10/25/a-guide-to-writing-git-commit-messages/
EGit - Contributor Guide http://wiki.eclipse.org/EGit/**Contributor_Guidehttp://wiki.eclipse.org/EGit/Contributor_Guide
Gerrit Code Review - Contributing https://gerrit-review.**googlesource.com/**Documentation/dev-** contributing.htmlhttps://gerrit-review.googlesource.com/Documentation/dev-contributing.html
Proper Git Commit Messages and an Elegant Git History http://ablogaboutcode.com/**2011/03/23/proper-git-commit-** messages-and-an-elegant-git-**history/http://ablogaboutcode.com/2011/03/23/proper-git-commit-messages-and-an-elegant-git-history/
-- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/**User:Qgilhttp://www.mediawiki.org/wiki/User:Qgil
______________________________**_________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l