Talk:Gerrit/Commit message guidelines/Archive 1

Wrapping
Is Gerrit really unable to display text correctly if not manually wrapped, as the text currently suggests? Seems worth a bug upstream. --Nemo 21:09, 30 March 2012 (UTC)


 * That is by design I guess. Some old people, like me, tends to like having the text already wrapped :-D Antoine &#34;hashar&#34; Musso (talk) 18:54, 31 March 2012 (UTC)

Bug number in parentheses
Is it set in stone that the bug number must be in parentheses?

This wastes two character in a line that is very limited. Parentheses are not needed to make the bug number stand out. Gerrit shows it as a link and makes it distinct enough.

I suggest removing the parentheses. --Amir E. Aharoni (talk) 06:39, 18 June 2012 (UTC)
 * I would prefer to move from 65 to 72 chars for the first line, because these adds in readability.
 * Or maybe should we more generic in the first line instead to want to give all information there. --Dereckson (talk) 07:03, 18 June 2012 (UTC)

Patch set documentation
Since the first commits to the Wikimedia Gerrit repo, it has been the practice of describing subsequent patch sets (amends) in the commit message. Dereckson commented in this commit that this is not a good idea, and I tend to agree.

Descriptions of amends are interesting in the course of the patch development. They are less relevant after merging, because the final repo only shows the last amend. So it may be better to suggest to write the amend descriptions in the review comments in Gerrit and to write the commit message as a description of the latest amend.

Other thoughts? --Amir E. Aharoni (talk) 06:39, 18 June 2012 (UTC)


 * I just send the new patch set then comment on it. This way people receive a mail notification describing what changed in the new patchset.  Once the commit is merged, we probably have no interest in how we got there. Antoine &#34;hashar&#34; Musso (talk) 20:04, 27 June 2012 (UTC)

(bug 12345) or (Bug 12345)?
There are currently tho school in commits.

About two third of the commits use "(bug ...)" but some developers prefer to capitalize, as it's the first word.

Shouldn't we take a harmonization decision between those two variants?

Why it's important to have an harmonization on this matter? That will improve readability when you read the list of the commits to distinguish between the bug fixing changesets and the others. As long as there are (Bug ....) and (bug ...), we don't have this visual help to see there are lines starting by the same content. --Dereckson (talk) 08:33, 19 June 2012 (UTC)

Suggesting to describe before/after
Usually people only describe what they changed in the commit; that is, how the software is supposed to behave after the change. Very frequently the commit message doesn't describe the situation before the change. It would be useful to describe the situation before the change and the reason that it should be changed, to help the reviewer who may misunderstand the context without it. This may not be required for commits that fix bugs that are documented in Bugzilla, but many commits are out-of-the-blue patches without a Bugzilla context.

An example of a common current commit message:

An example of the proposed commit message:

(It's based on an actual commit: https://gerrit.wikimedia.org/r/#/c/14780/ .)

What do you think about adding this to the best practices? --Amir E. Aharoni (talk) 21:03, 9 July 2012 (UTC)

Bug number in commit messages
Reminder to watchers: there isn't a very robust consensus about the removal of bug number from first line of commit message. Remember that there isn't any tool to list the bugs that were fixed in a release, so manually updating release notes in the same commit that fixes a bug is now your only option to let people know. --Nemo 14:30, 10 March 2013 (UTC)