Hey all,
Unfortunately the combination of using commit summaries in release notes and the mass-merger of Wikidata code means that we now about several hundred somewhat cryptic commit summaries in the release notes [1].
IMHO it might be a good idea for everyone to get into the habit of using clear commit summaries regardless of whether or not they're directly committing to core/master, if not overly time-consuming. This would make it a lot easier for people like me who wade through the automated release notes
Thanks! Harry
-- Harry Burt (User:Jarry1250)
[1] https://www.mediawiki.org/w/index.php?title=MediaWiki_1.21/wmf2
Le 16/10/12 17:41, Harry Burt a écrit :
Hey all,
Unfortunately the combination of using commit summaries in release notes and the mass-merger of Wikidata code means that we now about several hundred somewhat cryptic commit summaries in the release notes [1]. [1] https://www.mediawiki.org/w/index.php?title=MediaWiki_1.21/wmf2
Hello,
That is unfortunate. We might want to rebuild the 1.21/wmf2 release note by excluding the Wikidata branch change and manually craft a section dedicated to that merge.
IMHO it might be a good idea for everyone to get into the habit of using clear commit summaries regardless of whether or not they're directly committing to core/master, if not overly time-consuming. This would make it a lot easier for people like me who wade through the automated release notes
During our first weeks using git, we have been asking people to write nice summary lines since they are used in Gerrit email notifications and in git log. I wrote a basic guideline (which has been improved since) that people can be pointed at:
https://www.mediawiki.org/wiki/Git/Commit_message_guidelines
cheers,
On Thursday, October 18, 2012 at 1:08 AM, Antoine Musso wrote:
During our first weeks using git, we have been asking people to write nice summary lines since they are used in Gerrit email notifications and in git log. I wrote a basic guideline (which has been improved since) that people can be pointed at:
https://www.mediawiki.org/wiki/Git/Commit_message_guidelines
This is very useful! I wonder if we could inject the URL into the comment part of the commit template, using something like the commit.template configuration variable[1]. Maybe it's something git review -s could set up.
[1]: http://git-scm.com/book/en/Customizing-Git-Git-Configuration
-- Ori Livneh ori@wikimedia.org
On 18/10/12 19:08, Antoine Musso wrote:
During our first weeks using git, we have been asking people to write nice summary lines since they are used in Gerrit email notifications and in git log. I wrote a basic guideline (which has been improved since) that people can be pointed at:
https://www.mediawiki.org/wiki/Git/Commit_message_guidelines
That's interesting. I usually don't put the bug number in the first line, because there's not enough room for it. There's barely enough room to fit in the most simplified summary of a change in 62 characters, and the bug number would take up 12, leaving you only 50.
Consider if you wanted to say what function it is you changed. Here's a histogram of lengths of "ClassName::methodName" strings from $wgAutoloadClasses on my test wiki:
length count ---------------- 9 1 10 1 11 4 12 7 13 3 14 2 15 6 16 13 17 15 18 16 19 29 20 32 21 55 22 62 23 106 24 149 25 152 26 177 27 225 28 258 29 297 30 301 31 338 32 355 33 328 34 290 35 282 36 240 37 204 38 220 39 172 40 173 41 141 42 126 43 80 44 88 45 69 46 63 47 53 48 27 49 31 50 26 51 23 52 9 53 10 54 10 55 4 56 5 57 5 58 8 59 1 60 4 61 4 62 3 63 1 64 1 65 2 66 1 67 0 68 1 69 1 70 0 71 0 72 1 73 1
Really, 62 characters is ridiculously short, and the existence of that limit is a flaw in git, but at least you can write a typical method name preceded by the word "fixed". With a limit of 50, you often can't.
-- Tim Starling
Keep in mind this is not a problem with git, but a problem with gerrit. Git will work perfectly fine with summary lines over 62 characters (try git shortlog). *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Thu, Oct 18, 2012 at 5:08 AM, Tim Starling tstarling@wikimedia.orgwrote:
On 18/10/12 19:08, Antoine Musso wrote:
During our first weeks using git, we have been asking people to write nice summary lines since they are used in Gerrit email notifications and in git log. I wrote a basic guideline (which has been improved since) that people can be pointed at:
https://www.mediawiki.org/wiki/Git/Commit_message_guidelines
That's interesting. I usually don't put the bug number in the first line, because there's not enough room for it. There's barely enough room to fit in the most simplified summary of a change in 62 characters, and the bug number would take up 12, leaving you only 50.
Consider if you wanted to say what function it is you changed. Here's a histogram of lengths of "ClassName::methodName" strings from $wgAutoloadClasses on my test wiki:
length count
9 1 10 1 11 4 12 7 13 3 14 2 15 6 16 13 17 15 18 16 19 29 20 32 21 55 22 62 23 106 24 149 25 152 26 177 27 225 28 258 29 297 30 301 31 338 32 355 33 328 34 290 35 282 36 240 37 204 38 220 39 172 40 173 41 141 42 126 43 80 44 88 45 69 46 63 47 53 48 27 49 31 50 26 51 23 52 9 53 10 54 10 55 4 56 5 57 5 58 8 59 1 60 4 61 4 62 3 63 1 64 1 65 2 66 1 67 0 68 1 69 1 70 0 71 0 72 1 73 1
Really, 62 characters is ridiculously short, and the existence of that limit is a flaw in git, but at least you can write a typical method name preceded by the word "fixed". With a limit of 50, you often can't.
-- Tim Starling
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Thu, Oct 18, 2012 at 5:08 AM, Tim Starling tstarling@wikimedia.org wrote:
On 18/10/12 19:08, Antoine Musso wrote:
During our first weeks using git, we have been asking people to write nice summary lines since they are used in Gerrit email notifications and in git log. I wrote a basic guideline (which has been improved since) that people can be pointed at:
https://www.mediawiki.org/wiki/Git/Commit_message_guidelines
That's interesting. I usually don't put the bug number in the first line, because there's not enough room for it. There's barely enough room to fit in the most simplified summary of a change in 62 characters, and the bug number would take up 12, leaving you only 50.
Indeed. And actually, I've kind of gotten out of the habit of doing this as well. The "standard practice" is actually for people to do it in the footer of the message, along with things like the Change-Id and Signed-Off-By. For example:
''' Fixing some broken feature
This was broken because......
Bug: 12345 Change-Id: .... '''
I rather prefer this format, to be honest. And actually, Gerrit has a feature (we're not making use of, but we easily could if people are interested) where you can track those bug footer notes. We could easily add regexes for Bugzilla and RT (gerrit calls them "tracking ids") if that's something people would use.
-Chad
wikitech-l@lists.wikimedia.org