Ok, I think everyone is over-reading my suggestion to drive release notes from commit messages. I'm sure there will always be a manual, human step to convert the commit messages between two points into release notes, I'm just saying that if we are consistent with our commit messages and take the time to write good ones, that we can drive that effort close to zero.
Commit messages cannot be edited after the fact but git does support annotations to existing commits for that kind of fix-up. Let's just agree to follow the same standard of commit message for now. On 6 June 2013 11:39, Noah Slater <[email protected]> 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? > > > > > On 6 June 2013 09:40, Benoit Chesneau <[email protected]> wrote: > >> On Thu, Jun 6, 2013 at 10:26 AM, Benoit Chesneau <[email protected]> >> wrote: >> > On Thu, Jun 6, 2013 at 9:58 AM, Garren Smith <[email protected]> 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
