On Thu, Jun 6, 2013 at 12:39 PM, Noah Slater <nsla...@apache.org> wrote: > My concern with commit messages -> release notes is that we're human, and > mistakes will happen. How easy will it be to go in and edit commit > messages? If we can do that, then we can write a tool that generates the > release notes, and put the onus on committers to edit commit messages as > necessary until the release notes are representative. Perhaps this is a > good way of enforcing Git hygiene? > > >
If we go to a system where a commit in master or release branch can happen only if he get one or more review, (ie +1) then we are fine. On other branch it is still time to rebase with a new commit msg when it's about commiting on master imo. - benoit > On 6 June 2013 09:40, Benoit Chesneau <bchesn...@gmail.com> wrote: > >> On Thu, Jun 6, 2013 at 10:26 AM, Benoit Chesneau <bchesn...@gmail.com> >> wrote: >> > On Thu, Jun 6, 2013 at 9:58 AM, Garren Smith <gar...@apache.org> wrote: >> >> I agree with Jason and Bob, the simplest way is going to be the easiest >> for us to implement. >> >> >> >> With us wanting to use commit messages in the release notes, could we >> not mark specific commit messages e.g. [Release Notes] so that only >> specific commit messages get added into the release notes and other commits >> get ignored. >> >> >> >> >> > >> > why would you want to parse a commit message to find a release branch >> > when you could just do >> > >> > $ git branch -a >> > $ git checkout <branchname> >> > >> > ? >> > >> > - benoit >> >> >> mmmm taking some coffee i sbetter, but having a commit message >> formmatted like this: >> >> >> Short description in 1 line >> >> description >> >> close #COUCHDB-XXXX >> >> >> where final line can be >> >> - `close TICKET` for features >> - `fix TICKET` for fixes >> >> works generally well to build changelogs and reports. Also the 1 line >> on top could also be used in messaging systems :) >> >> - benoit >> > > > > -- > NS
