[katello-devel] Commit Messages
Petr Chalupa
pchalupa at redhat.com
Wed May 15 19:37:45 UTC 2013
On 15.05.13 13:29, Eric D Helms wrote:
> I don't think the component name has to be unique, just informative.
> That way when a pull request is opened it's easy to see what that pull
> request affects both in the list of requests and in email. Further, this
> makes looking at the git log easier to read as you can scan quickly for
> what commits targeted.
I see your point, makes sense. Still I would not make it obligatory.
Component name does make sense for bigger PRs for a smaller ones with
one or two commits I do not see the advantage of having a component prefix.
> And I agree CI seems like it could be annoying if you had a lot of
> commits before getting your code in front of CI.
Yeah we should combine it with a commit hook as marek suggested, to
avoid that.
> Eric
>
> On May 15, 2013 4:58 AM, "Petr Chalupa" <pchalupa at redhat.com
> <mailto:pchalupa at redhat.com>> wrote:
>
> My 2cents:
>
> 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.
>
> We should have a test in CI to test that commit-messages are ok.
>
> 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
> <http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html>
> https://github.com/torvalds/__subsurface/blob/master/README#__L231
> <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
> <mailto:ericdhelms at gmail.com>>
> To: "katello-devel" <katello-devel at redhat.com
> <mailto: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:__DescribeYourChanges
> <https://fedorahosted.org/katello/wiki/DevProcess#CommitMessages:DescribeYourChanges>
>
>
> - Eric
>
> _________________________________________________
> katello-devel mailing list
> katello-devel at redhat.com <mailto:katello-devel at redhat.com>
> https://www.redhat.com/__mailman/listinfo/katello-devel
> <https://www.redhat.com/mailman/listinfo/katello-devel>
>
>
> _________________________________________________
> katello-devel mailing list
> katello-devel at redhat.com <mailto:katello-devel at redhat.com>
> https://www.redhat.com/__mailman/listinfo/katello-devel
> <https://www.redhat.com/mailman/listinfo/katello-devel>
>
>
> _________________________________________________
> katello-devel mailing list
> katello-devel at redhat.com <mailto:katello-devel at redhat.com>
> https://www.redhat.com/__mailman/listinfo/katello-devel
> <https://www.redhat.com/mailman/listinfo/katello-devel>
>
More information about the katello-devel
mailing list