[gmx-developers] some notes on using redmine

[Mark Abraham]

On 9/01/2011 12:56 PM, Mark Abraham wrote:
> On 9/01/2011 7:58 AM, David van der Spoel wrote:
>> On 2011-01-08 20.36, Teemu Murtola wrote:
>>> On Fri, Jan 7, 2011 at 01:56, Mark Abraham<Mark.Abraham at anu.edu.au>  
>>> wrote:
>>>> I think it would be overkill to require the creation or linking of 
>>>> a Redmine
>>>> issue for every commit, however. Thoughts?
>>>
>>> Requiring it could indeed be overkill, but we could try to make it a
>>> strong recommendation.  This way, Redmine would get much more easily
>>> integrated into the workflow, because people would be forced to think
>>> about the issue at least a bit.  Adding something like IssueID #NNN at
>>> the end of a commit message should be enough (or perhaps configuring
>>> Redmine such that it would link commits that start with [#NNN]) in
>>> cases where the issue number does not naturally fit into the commit
>>> message.
>>>
>>> Another thing that would be worth thinking about is the formatting of
>>> the commit messages.  Many git tools, and it seems that Redmine as
>>> well, work somewhat better if commit messages are formatted according
>>> to the guidelines put forth in many git tutorials: first a max
>>> ~50-char line with a short summary, then an empty line, and then a
>>> more detailed description of the commit (many places suggest max 72
>>> character lines, and, e.g., gitk works badly with long lines).  If
>>> nothing else, this would make the activity page in Redmine more
>>> readable.
>>>
>> It would be great if this kind of thing were not dependent on the 
>> memory of developers. Many of us (at least I) put in a patch now and 
>> then and have a hard time remembering such guidelines. Is there a way 
>> we can enforce a certain format?
>
> Indeed, there is a way. git can call a bunch of scripts on both the 
> client when commits are made, and on the server when the commits are 
> pushed, that can do all kinds of things. For example, the post-commit 
> emails we get now are generated by such a script. Now is a great time 
> to think about using these effectively.

To answer David's specific question, one such script can provide a 
template commit message when you use "git commit", i.e. without -m. Now 
your editor of choice opens a copy of the template commit message and 
you have to fill in the blanks.

Mark