On Feb 9, 2011, at 3:09 PM, Luis Lavena wrote: > On Wed, Feb 9, 2011 at 7:40 PM, Ryan Davis <ryand-r...@zenspider.com> wrote: >> We're going to start using a convention I've been using in perforce and on >> my jobs for years now. Commit messages will have lines prefixed to convey >> what type of change they are: >> >> ! major change / enhancement >> + minor change / enhancement >> - bug fix >> not worth mentioning in the release >> >> No wrapping lines in your commit message. If you have 2 changes they go on >> separate lines. >> > > The problem I see with this approach are changes that span across > multiple commits and touch different files. > > If we use the same description for each commit, it looses the a way > for doing quick log and see when things are introduced and what.
I do the same, so I use a ! + - for one commit and omit the signifier for the rest. > I personally prefer updating History.txt myself and include: > > == (Not Released) > > * Bugfixes: > * > > Etc. you get the idea. > > Either by automated tools or not, parsing before a release still > remains something manual, so why not make it more easy for > contributors to work directly into that file? > > In case of pull requests, after a merge I update the History to > reflect the changes taking part of the pull request description and > given the proper attribution. I think we can adjust the git history tool to separate direct commits from those applied through pull requests in order to figure out proper messages for commits from pull requests. > If we enforce this, needs to be documented in a contribution document > so pull requests commits can follow these rules and is less work for > us. Sure. _______________________________________________ Rubygems-developers mailing list http://rubyforge.org/projects/rubygems Rubygems-developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
