couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Smith <...@apache.org>
Subject Re: [DISCUSS] Git workflow
Date Thu, 06 Jun 2013 11:17:26 GMT
Agreed!


On Thu, Jun 6, 2013 at 5:48 PM, Robert Newson <rnewson@apache.org> wrote:

> 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 <nslater@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?
> >
> >
> >
> >
> > On 6 June 2013 09:40, Benoit Chesneau <bchesneau@gmail.com> wrote:
> >
> >> On Thu, Jun 6, 2013 at 10:26 AM, Benoit Chesneau <bchesneau@gmail.com>
> >> wrote:
> >> > On Thu, Jun 6, 2013 at 9:58 AM, Garren Smith <garren@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
>

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