[Insight-developers] Commit message prefixes
Alexandre GOUAILLARD
agouaillard at gmail.com
Sun Oct 31 01:17:17 EDT 2010
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
>
>
More information about the Insight-developers
mailing list