[katello-devel] Commit Messages

[Petr Chalupa]

On 15.05.13 12:31, Marek Hulan wrote:
>>From my point of view
>
>> I would have hard limit at 80 characters, "74 characters or so" seems
>> vague to me. I would use same limit for summary.
>>    * just one limit
>>    * sometimes is hard to squeeze summary into 80chars it will be even
>> harder to 50chars.
> Agree, just one note - don't try to explain every change in a title, that's
> why we have description, titles can be few words I think.
>
>> We should have a test in CI to test that commit-messages are ok.
> That would introduce a lot of extra work after something is pushed. I'd
> recommend setting up some kind of a git hook on developer side so you can be
> sure not to create any wrong commit. Then it would make sense to add check to
> CI.

Good point, having both would be best.

>
> --
> Marek
>
>>
>> I don't like the component usage for stories. When people are working on
>> same thing, there are often small inconsistencies. The component name
>> won't be unique for a story over time. It does not reference the  story
>> in any way.
>>
>> I would omit component name in summary. Alternative is to use following
>> alias:
>>
>> logpr = !sh -c 'git log --reverse --grep=\"Merge pull request\" -n 1
>> --ancestry-path master ^$1 $@' -
>>
>> to find in which pull-request was a given commit merged, e.g.
>>
>> git logpr 4b6d8f9 --oneline
>> d2a35bc Merge pull request #2258 from daviddavis/temp_1368456830
>>
>> so 4b6d8f9 is part of #2258 pull-request, and we can see the whole work
>> done there.
>>
>> Petr
>>
>> On 14.05.13 15:24, David Davis wrote:
>>> As a user of git log and git shortlog, I was going to bring this up too. I
>>> see a lot of people going over 70 characters for the short message in
>>> commit messages. The git tools are really based around a short message
>>> and long message and this makes it hard to read commits in git log and
>>> git shortlog. Also, I think we should limit the short message to 50 chars
>>> which is what Linus and other git gurus recommend. More information
>>> below.
>>>
>>> http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
>>> https://github.com/torvalds/subsurface/blob/master/README#L231
>>>
>>> Regarding adding components though, I think it's generally a good idea as
>>> well. I would prefer to move to colons which Linus uses in his example
>>> (and it's also one char shorter) but dashes are fine too.
>>>
>>> David
>>>
>>> ----- Original Message -----
>>>
>>>> From: "Eric D Helms" <ericdhelms at gmail.com>
>>>> To: "katello-devel" <katello-devel at redhat.com>
>>>> Sent: Tuesday, May 14, 2013 9:11:38 AM
>>>> Subject: [katello-devel] Commit Messages
>>>>
>>>> I was reading over our Development Process wiki page, and while there are
>>>> some out of date items that need cleaning up on it, there is one item
>>>> that I wanted to encourage developers to follow. This is a rule of thumb
>>>> I try to follow with regards to commit messages that I think helps when
>>>> reading through the git log, looking through previous changes or when
>>>> seeing a pull request opened up. To quote the page [1]:
>>>>
>>>> "Commit messages should take the form:
>>>>
>>>> Component: Short summary with no more than 70 characters
>>>>
>>>> The next lines of your commit can contain more lines with paragraphs
>>>> separated by a blank line in between each paragraph. These should also be
>>>> wrapped at 74 or so characters. Why do this? Because it displays better
>>>> in git log and on github.
>>>>
>>>> The component is actual user story being worked on. Keep it same for
>>>> multiple commits. You can also use dash instead of colon, example:
>>>>
>>>> packagegroups - system test
>>>> packagegroups - unit test for CLI
>>>> packagegroups - unit test
>>>> packagegroups - adding support in CLI
>>>> packagegroups - adding support in backend
>>>> "
>>>>
>>>> The part of that I think we could benefit more from is the inclusion of
>>>> the
>>>> component name (just like we do bugzilla and github issue numbers to
>>>> preface bug fixes) as part of commit messages. For example:
>>>>
>>>> Menu -
>>>> Content View Definition -
>>>> Comps -
>>>> Rel-eng -
>>>> API -
>>>> Systems -
>>>>
>>>> Ref:
>>>> https://fedorahosted.org/katello/wiki/DevProcess#CommitMessages:DescribeY
>>>> ourChanges
>>>>
>>>>
>>>> - Eric
>>>>
>>>> _______________________________________________
>>>> katello-devel mailing list
>>>> katello-devel at redhat.com
>>>> https://www.redhat.com/mailman/listinfo/katello-devel
>>>
>>> _______________________________________________
>>> katello-devel mailing list
>>> katello-devel at redhat.com
>>> https://www.redhat.com/mailman/listinfo/katello-devel
>>
>> _______________________________________________
>> katello-devel mailing list
>> katello-devel at redhat.com
>> https://www.redhat.com/mailman/listinfo/katello-devel