[Insight-developers] Commit message prefixes

Matthew McCormick (thewtex) matt at mmmccormick.com
Sun Nov 14 00:24:13 EST 2010


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
>


More information about the Insight-developers mailing list