+1, maybe we should all follow it :) Simon Mac Donald http://hi.im/simonmacdonald
On Fri, Jan 11, 2013 at 1:29 PM, Michael Brooks <[email protected]> wrote: > Looks really good, nice work! > > On Fri, Jan 11, 2013 at 9:59 AM, Marcel Kinard <[email protected]> wrote: > >> Good points, Michael. >> >> Done. Please tweak further where desired. http://wiki.apache.org/** >> cordova/ContributorWorkflow<http://wiki.apache.org/cordova/ContributorWorkflow> >> >> -- Marcel >> >> >> On 1/10/2013 2:23 PM, Michael Brooks wrote: >> >>> @Marcel nice work, I agree we should add this to the wiki article. >>> >>> One note is that I believe you should have an empty line between the >>> summary and detailed body. >>> >>> The Pro Git Books [1] summaries the git messages templates as: >>> >>> Short (50 chars or less) summary of changes >>> >>> More detailed explanatory text, if necessary. Wrap it to about 72 >>> characters or so. In some contexts, the first line is treated as the >>> subject of an email and the rest of the text as the body. The blank >>> line separating the summary from the body is critical (unless you omit >>> the body entirely); tools like rebase can get confused if you run the >>> two together. >>> >>> Further paragraphs come after blank lines. >>> >>> - Bullet points are okay, too >>> >>> - Typically a hyphen or asterisk is used for the bullet, preceded by a >>> single space, with blank lines in between, but conventions vary here >>> >>> >>> @Josh >>> >>> I think short commit messages and multiple tiny commits are fine (and >>> good). For me, the most important part of the commit message is a >>> reference >>> to the issue that it is related to. For example, "[CB-1287] Rename such >>> and >>> such." The issue reference groups all of the tiny commits into a common >>> task. >>> >>> [1] >>> http://git-scm.com/book/ch5-2.**html#Commit-Guidelines<http://git-scm.com/book/ch5-2.html#Commit-Guidelines> >>> >>>
