Really I just want to make sure that a commit I make that I know needs to be pushed into the next 4.0 bugfix release gets there. Since someone else is in charge of maintaining 4.0 and merging bug fixes, I can't do it myself, and I'm not really sure how it works now. For example, does that maintainer look through a JIRA report and only merge bugfixes listed there?
On Wed, Nov 7, 2012 at 11:03 AM, Rohit Yadav <rohit.ya...@citrix.com> wrote: > I'm not sure how (cherry picking, pull based on commit message) this will > work, but it's good idea to mark the commit with some tag with say branch > so we always commit on master? > (Bugfix-for or Branch: <branches> ) > Branch: 4.0, master #(comma separated branch names). > Bug-id: CLOUDSTACK-xxx > > This may be ambiguous, says some developer did not know if some commit > would apply for some branch? Another issue is to encourage everyone of us > to use this convention. > If we could solve it, that would be great. > > ________________________________________ > From: Marcus Sorensen [shadow...@gmail.com] > Sent: Wednesday, November 07, 2012 8:56 PM > To: cloudstack-dev@incubator.apache.org > Subject: Re: Rant: Request for better commit messages > > Should we add a line to this commit message, where people can mark whether > this patch should be considered for the next bugfix release? Or is that all > handled/tracked through JIRA or some other means? I just thought it would > be nice for the guy maintaining a release to be able to eventually pull in > stuff based on the commit messages. It also allows the committers to give > some sort of indication that commit X is important and needs to go into the > bugfix. > > For now I'm just adding "Bugfix-for: 4.0" to my commits. > > > On Thu, Oct 18, 2012 at 3:59 PM, Marcus Sorensen <shadow...@gmail.com > >wrote: > > > Ok, this is now in master, see 9ba7509c70fe82a8ce0b08826d424de452aef1d2 > > > > set it up by running the following from your incubator-cloudstack dir: > > > > 'ln -s ../../tools/git/prepare-commit-msg .git/hooks/prepare-commit-msg' > > > > Developers can also optionally commit different prepare-commit-msg > > scripts for each branch, and the link will point to the one you're on. > > > > On Sun, Oct 14, 2012 at 10:19 AM, Rohit Yadav <rohit.ya...@citrix.com> > > wrote: > > > > > > On 14-Oct-2012, at 9:18 PM, Marcus Sorensen <shadow...@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 <yourem...@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.ya...@citrix.com> > wrote: > > >> > > >>> > > >>> On 12-Oct-2012, at 10:29 PM, Marcus Sorensen <shadow...@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.ya...@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 <shadow...@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 < > w...@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.ya...@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> > > >>> > > >>> > > > > > >
