On Mon, Mar 4, 2013 at 7:06 AM, Quim Gil <qgil(a)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-message<http://stackoverflow.com/questions/14409413/sea…
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/GitCommitMessages<https://wiki.opensta…
Chromium - Contributing code
http://www.chromium.org/**developers/contributing-code<http://www.chromi…
Qt - Introduction to Gerrit
http://qt-project.org/wiki/**Gerrit-Introduction<http://qt-project.org/w…
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-…
EGit - Contributor Guide
http://wiki.eclipse.org/EGit/**Contributor_Guide<http://wiki.eclipse.org…
Gerrit Code Review - Contributing
https://gerrit-review.**googlesource.com/**Documentation/dev-**
contributing.html<https://gerrit-review.googlesource.com/Documentation/d…
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…
--
Quim Gil
Technical Contributor Coordinator @ Wikimedia Foundation
http://www.mediawiki.org/wiki/**User:Qgil<http://www.mediawiki.org/wiki/…
______________________________**_________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/**mailman/listinfo/wikitech-l<https://lists.…
--
Cheers,
Nischay Nahata
nischayn22.in