incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@tumbolia.org>
Subject Re: Rant: Request for better commit messages
Date Tue, 16 Oct 2012 08:47:23 GMT
If there's something Infra might be able to provide, you should start a
thread at infrastructure@apache.org to check. They can be
quite accommodating. Especially around Git, etc. One of the things I
suggested to them was that it might be nice if CLOUDSTACK-BUGID in a commit
message automatically appended the commit to the ticket with a link to the
changeset. Not sure what the status of that is. I think there is an open
ticket for it.

On Sun, Oct 14, 2012 at 5:29 PM, Marcus Sorensen <shadowsor@gmail.com>wrote:

> Yeah, that's an option too. The reason I was thinking going the hook
> route was because we could provide one file that will work for
> everyone (auto populate the signed-off-by and perhaps other things).
> Basically because it's scriptable. Then they can just copy it to
> .git/hooks on their own. That's the nice thing about the git model
> though, people can do it how they like.
>
> On Sun, Oct 14, 2012 at 10:19 AM, Rohit Yadav <rohit.yadav@citrix.com>
> wrote:
> >
> > On 14-Oct-2012, at 9:18 PM, Marcus Sorensen <shadowsor@gmail.com> wrote:
> >
> >> I'm by no means a git guru, but in searching around it didn't seem like
> >> there was a way to enforce the application of hooks from the repo side.
> >> I'm not sure we'd want to anyway. I was just going to commit the file
> and
> >> then add instructions on the wiki for people to add it in their local
> repo
> >> config.
> >
> > I think that's fine. Instead of hooks what people can do is add a commit
> template to their local git configuration.
> > http://git-scm.com/book/en/Customizing-Git-Git-Configuration
> >
> > Checkout commit.template, add following to your ~/.gitconfig:
> > [commit]
> >   template = ~/.gitmessage
> >
> > And create a ~/.gitmessage like:
> > #Header: one line explaination
> > #
> > #Body of commit message explaining things in more detail, possibly
> giving some
> > #background about the issue being fixed, etc. Maybe use bullets:
> > #  - Write in present tense
> > #  - Keep text width of commit message within 80 characters.
> > #
> > #Use more than one paragraphs, that's is fine.
> > #
> > #Reviewed-by: Person or link to review on review.apache.org
> > #Reported-by: whoever-reported-it, if applicable
> > #Signed-off-by: Your Name <youremail@yourhost.com>
> >
> > Now every time one does git commit, she will see this in their editor
> and use this as a reminder to write better commit message.
> > For example my:
> > gitconfig:
> https://github.com/bhaisaab/dotfiles/blob/master/git/gitconfig
> > gitmessage:
> https://github.com/bhaisaab/dotfiles/blob/master/git/gitmessage
> >
> > Regards.
> >
> >> On Oct 14, 2012 4:07 AM, "Rohit Yadav" <rohit.yadav@citrix.com> wrote:
> >>
> >>>
> >>> On 12-Oct-2012, at 10:29 PM, Marcus Sorensen <shadowsor@gmail.com>
> wrote:
> >>>
> >>>> Sure thing.  A few questions:
> >>>>
> >>>> the "CLOUDSTACK-<BUGID> prefix:" line, should that be changed
to
> >>>> simply "Bug id:"?
> >>>
> >>> I guess as there are already several commits that follow
> CLOUDSTACK-BUGID
> >>> convention, we should continue that.
> >>> Also, there are commits with bug id's of old jira, like CS-16414 etc.
> >>>
> >>>> I'm assuming that if the commit is a bug fix, the
> >>>> fix will already be described in the summary and detail of the commit.
> >>>> Or are we looking for something else here other than a description?
I
> >>>> could just see this being redundant, but perhaps I don't understand
> >>>> what's being asked for on that line. Should id describe the bug itself
> >>>> in one line, rather than the bug fix?
> >>>
> >>> Whatever makes sense, I usually write what that commit does in one
> line.
> >>>
> >>>>
> >>>> I'm also assuming it's ok to add the "Signed-off-by:" to the message.
> >>>> I realize that some people will have their own configs that already
do
> >>>> this, or be used to using -s to auto-add it to the message, but
> >>>> judging by the logs it seems that the majority don't. So hopefully
> >>>> this doesn't upset anyone horribly :-) They can always change their
> >>>> copy since the hook will need to be manually installed.
> >>>
> >>> I've just put up bunch of guidelines on the wiki, let's take whatever
> >>> seems good and follow whatever makes sense.
> >>> My whole intension was to bring up the issue that a short commit
> message
> >>> makes it hard for folks to follow commits.
> >>>
> >>>> Attached is an example commit message generated by the hook so far.
> >>>
> >>> Cool, I guess you would have to contact someone from ASF infra to set
> this
> >>> up.
> >>>
> >>>> I
> >>>> left in the default comment message as well, simply because it
> >>>> includes a list of what's modified,etc for reference when typing up
> >>>> the notes.
> >>>
> >>> --
> >>> Rohit
> >>>
> >>>>
> >>>> On Fri, Oct 12, 2012 at 2:56 AM, Rohit Yadav <rohit.yadav@citrix.com>
> >>> wrote:
> >>>>>
> >>>>> I ported an old wiki from wiki.cloudstack to cwiki.a.o
> >>>>>
> >>>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-CommitMessages
> >>>>>
> >>>>> Pl. check and edit as needed.
> >>>>>
> >>>>> One more thing, I checked looks like ASF infra guys have upgraded
> their
> >>> review board.
> >>>>> The bug (
> >>>
> http://code.google.com/p/reviewboard/issues/detail?id=2690&thanks=2690&ts=1343826104
> )
> >>> got fixed so now downloading the diff downloads the actual uploaded git
> >>> formatted patch.
> >>>>>
> >>>>> On 12-Oct-2012, at 2:42 AM, Marcus Sorensen <shadowsor@gmail.com>
> >>> wrote:
> >>>>>
> >>>>>> Might be cool if we could make/document git hooks for a standard
> >>> message form.
> >>>>>
> >>>>> Marcus it's a good idea, pl. check if we can add git hooks to ASF
> repo
> >>> that would be great.
> >>>>>
> >>>>> Regards.
> >>>>>
> >>>>>>
> >>>>>> On Thu, Oct 11, 2012 at 3:05 PM, Wido den Hollander <wido@widodh.nl
> >
> >>> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>> On 10/10/2012 08:50 PM, Noah Slater wrote:
> >>>>>>>>
> >>>>>>>> Perhaps we could document this on the wiki, as part
of a nascent
> >>> coding
> >>>>>>>> standards policy?
> >>>>>>>
> >>>>>>>
> >>>>>>> I'd say so. We already have a coding convention, it's just
a small
> >>> step to
> >>>>>>> add a commit convention.
> >>>>>>>
> >>>>>>> I personally like 'clean' GIT repos with clear commit messages.
> >>>>>>>
> >>>>>>> Wido
> >>>>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>> On Wed, Oct 10, 2012 at 8:01 AM, Rohit Yadav <
> rohit.yadav@citrix.com
> >>>>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> Hi folks,
> >>>>>>>>>
> >>>>>>>>> With due respect, I would like to request all the
committers and
> >>>>>>>>> contributors to write better commit message. [0]
> >>>>>>>>>
> >>>>>>>>> For example, a good commit message:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=384c03e42578f17432a483d5828aad64175d9c49
> >>>>>>>>>
> >>>>>>>>> A good commit message subject should have something
like this
> with
> >>> 80
> >>>>>>>>> chars width:
> >>>>>>>>> <Header line>: <short log description>
> >>>>>>>>> <blank line>
> >>>>>>>>> <body of commit message, explain things why,
what, how, etc.
> giving
> >>>>>>>>> background>
> >>>>>>>>> <bulleted points help>
> >>>>>>>>> <blank line>
> >>>>>>>>> <Reported-by: if it's a bug>
> >>>>>>>>> <Reviewed-by: if it was reviewed>
> >>>>>>>>> <Signed-off: turn on signature in your .gitconfig>
> >>>>>>>>>
> >>>>>>>>> This is what we follow on
> >>>>>>>>> http://git.videolan.org/?p=vlmc.git;a=shortlogand
they are crazy
> >>> about
> >>>>>>>>> commits and patches, they just don't accept junk
> >>>>>>>>> messages, even if code is fine. You may check, there
is no or few
> >>>>>>>>> reverts.
> >>>>>>>>>
> >>>>>>>>> When something breaks, I check all last commits
and do a git log
> -p
> >>>>>>>>> <file>
> >>>>>>>>> to go through recent changes to a file, in case
I think something
> >>> broke I
> >>>>>>>>> like to identify the changes that may have caused
it instead of
> >>> fixing it
> >>>>>>>>> which may introduce further problems. I use tig
and zsh to
> regularly
> >>>>>>>>> follow
> >>>>>>>>> commits and read commit messages.
> >>>>>>>>>
> >>>>>>>>> Also, please fix your editors and follow coding
conventions.
> >>>>>>>>>
> >>>>>>>>> [0] https://github.com/torvalds/subsurface/blob/master/README(at
> >>> the
> >>>>>>>>> end)
> >>>>>>>>>
> >>>>>>>>> Regards.
> >>>>>>>>> PS. I had to email about it as we're uncool with
our git commit
> >>> habits,
> >>>>>>>>> we
> >>>>>>>>> are doing triple or quadruple reverts, we need to
fix our habits.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=7bcbae5e91a4cd122d0efa7f2542eab73debb6df
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=c49f3beccfcd1257eca1ea06606fb55b3fdf5093
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=66daa1a2bc6e86adea265a8a0b8b512756c8f77c
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=828fa3389bbe7cd0378c4e55152d671932badca2
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=bb7f9ad9774019f4fdb4d72b2e32a36df9c89188
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=75e2a1012fccc01c639c7f41be564ac0e32088fb
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=5078dff6e76649fbc51e2b9c003fd8e03eef18f3
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=850433240401cd318f1d8d8b0fa2032a60d52c1f
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>
> >>>> <examplecommitmsg.txt>
> >>>
> >>>
> >
>



-- 
NS

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message