[Insight-developers] Commit message prefixes

[Hans Johnson]

I agree with Matt that this information should be presented to the developer
when making the commit so that they get used correctly.  In particular, I
never know what the proper syntax is for referencing the bug tracker.

Hans



On 11/13/10 11:24 PM, "Matthew McCormick (thewtex)" <matt at mmmccormick.com>
wrote:

> If the decision is to keep the commit prefixes, can we get the message
> that was in the comments when making a commit in CVS in Git?  If I
> remember correctly, it listed all the prefixes and when they should be
> used.  The contents of that file, where-ever it may be, could be added
> in the Git prepare-commit-msg hook.
> 
> Thanks,
> Matt
> 
> On Sun, Oct 31, 2010 at 12:17 AM, Alexandre GOUAILLARD
> <agouaillard at gmail.com> wrote:
>> I vote for the prefixes too
>> 
>> I agree with stephen to say, this kind of policy discussion should be
>> done (and triggered) by the ISC...
>> 
>> alex.
>> 
>> On Sat, Oct 30, 2010 at 9:00 AM, Jim Miller <millerjv at gmail.com> wrote:
>>> I think we should be able to write the summary line of the commit message
>>> with 73 characters. 73 vs 78 characters is not a deal breaker for me.
>>> I vote for keeping the prefixes to characterize the commit.
>>> 
>>> 
>>> 
>>> On Oct 29, 2010, at 2:27 PM, David Cole <david.cole at kitware.com> wrote:
>>> 
>>> On Fri, Oct 29, 2010 at 2:21 PM, David Doria <daviddoria at gmail.com> wrote:
>>>> 
>>>> On Fri, Oct 29, 2010 at 2:14 PM, Stephen Aylward
>>>> <stephen.aylward at kitware.com> wrote:
>>>>> 
>>>>> Ok,
>>>>> 
>>>>> I thought we had decided on ITK to use them many many years ago, and I
>>>>> hadn't heard of a discussion to change.   Perhaps it was the VTK
>>>>> folks.
>>>>> 
>>>>> We did previously have hooks for these, right?
>>>>> 
>>>>> Those 4-5 characters provide critical info.   If anything, we should
>>>>> welcome them for the space and time they do save for those creating
>>>>> the messages as well as those reading them.   They embody all things
>>>>> good about shorthand, codes, keys, names, IDs, stereotypes, labels,
>>>>> acronyms, and abbrevs. in a simple, universally accepted package that
>>>>> only requires 4-5 characters per usage :)
>>>>> 
>>>>> s
>>>> 
>>>> I'm not sure how many prefixes there are, but the ones I know are BUG,
>>>> STYLE, and ENH. If character count is the only concern, could they be
>>>> shortened to B:, S:, and E: ? I vote +1 for mandatory prefixes.
>>>> David
>>>> _______________________________________________
>>>> Powered by www.kitware.com
>>>> 
>>>> Visit other Kitware open-source projects at
>>>> http://www.kitware.com/opensource/opensource.html
>>>> 
>>>> Kitware offers ITK Training Courses, for more information visit:
>>>> http://kitware.com/products/protraining.html
>>>> 
>>>> Please keep messages on-topic and check the ITK FAQ at:
>>>> http://www.itk.org/Wiki/ITK_FAQ
>>>> 
>>>> Follow this link to subscribe/unsubscribe:
>>>> http://www.itk.org/mailman/listinfo/insight-developers
>>>> 
>>> 
>>> The argument was brought up due to the switch to git. Since there are many
>>> tools/places where git is used ( 'git log --oneline' or 'git shortlog' ) to
>>> produce summary output, it is best to describe the change in 78 characters
>>> or less for the first line, and then elaborate on that in subsequent lines
>>> if necessary.
>>> 
>>> Some commits are easy to describe in one line, others not so much.
>>> 
>>> For bug fix commits, Brad and I have taken to using "(#12345)" as the suffix
>>> on the first line.
>>> 
>>> All other commits should be sufficiently described in English such that
>>> reading the one line indicates it's type.
>>> 
>>> The prefixes make it harder to come up with the one-liner....
>>> 
>>> At least those are the arguments.
>>> 
>>> I prefer not having the prefixes enforced. That way, I can just describe
>>> what I did, and not worry about categorizing it and whether or not the
>>> community will agree with my own categorization.
>>> 
>>> 
>>> Another 2 cents,
>>> David C.
>>> 
>>> _______________________________________________
>>> Powered by www.kitware.com
>>> 
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>> 
>>> Kitware offers ITK Training Courses, for more information visit:
>>> http://kitware.com/products/protraining.html
>>> 
>>> Please keep messages on-topic and check the ITK FAQ at:
>>> http://www.itk.org/Wiki/ITK_FAQ
>>> 
>>> Follow this link to subscribe/unsubscribe:
>>> http://www.itk.org/mailman/listinfo/insight-developers
>>> 
>>> _______________________________________________
>>> Powered by www.kitware.com
>>> 
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>> 
>>> Kitware offers ITK Training Courses, for more information visit:
>>> http://kitware.com/products/protraining.html
>>> 
>>> Please keep messages on-topic and check the ITK FAQ at:
>>> http://www.itk.org/Wiki/ITK_FAQ
>>> 
>>> Follow this link to subscribe/unsubscribe:
>>> http://www.itk.org/mailman/listinfo/insight-developers
>>> 
>>> 
>> _______________________________________________
>> Powered by www.kitware.com
>> 
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>> 
>> Kitware offers ITK Training Courses, for more information visit:
>> http://kitware.com/products/protraining.html
>> 
>> Please keep messages on-topic and check the ITK FAQ at:
>> http://www.itk.org/Wiki/ITK_FAQ
>> 
>> Follow this link to subscribe/unsubscribe:
>> http://www.itk.org/mailman/listinfo/insight-developers
>> 
> _______________________________________________
> Powered by www.kitware.com
> 
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
> 
> Kitware offers ITK Training Courses, for more information visit:
> http://kitware.com/products/protraining.html
> 
> Please keep messages on-topic and check the ITK FAQ at:
> http://www.itk.org/Wiki/ITK_FAQ
> 
> Follow this link to subscribe/unsubscribe:
> http://www.itk.org/mailman/listinfo/insight-developers