[gmx-developers] some notes on using redmine

[Mark Abraham]

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.

The main inconvenience is that such scripts live in .git/hooks, which 
are not propagated by "git clone". Thus the developers would have to 
take care of installing the client-side ones themselves. However, it is 
very irritating at the end of a development process to have a server 
that will reject commits with messages that do not follow the ordained 
format, so there is incentive for developers to want to install such 
client-side hooks to use along the way. There are apparently ways to set 
up client-side hooks on a per-machine or per-user basis, rather than 
per-repository.

I've set up a Redmine task to discuss these issues - 
http://redmine.gromacs.org/issues/648. There's lots more information there.

Mark