On 2013-03-03 9:36 PM, "Quim Gil" qgil@wikimedia.org wrote:
[...]
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 don't see that as being an issue. If anything its an argument for putting bug number in header. You can't say (part 1/2 bug XXXX) in a footer line.
[...]
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):
[...]
If all the other open source projects jumped off a bridge... ;-)
Personally I prefer it in the first line. Second to a good one line summary of what was done, the bug number is the next most important thing. It allows one to see the context the commit was made in. Having it in the first line allows one to find it easily and have it displayed in various "one line" log formats ( including in gerrit when you get a list of commits)
The primary argument for changing the format is so gerrit can index it. Beyond the /sounds like a gerrit problem/ argument presented previously, I would additionally argue that that is not that useful a feature. (Even if on the surface it sounds cool). Any commit fixing a bug should be listed on the bug. If I have the bug number I can just look at the bug to find the relavent commits.
That said, at the end of the day I don't think it really matters much either way.
--bawolff
_______________________________________________
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l