On Wed, 2 Sep 2009, Ken Smith wrote:
On Wed, 2009-09-02 at 08:14 -0700, Doug Barton wrote:
That said, for RELENG_8 commits during the freeze re@ did ask in one
of their many messages about commit approvals to paste the complete
commit message in the MFC. So, bad Alfred, no cookie. :)
Just for clarification... We ask that you send your complete
*proposed commit message* in your *approval request*. We didn't say
that your commit message needs to include all of the text from the
commit to head.
So, bad Doug, no cookie. :-)
FWIW my preference is, as usual, somewhere in between the two
extremes. Duplicating a lengthy commit message in a merge is overkill
but in those cases a short (one sentence max) summary of what changed
being in the merge commit message is helpful. For example when
looking through the commits for release notes fodder it can help. It
also helps people who take the peer review of commits being done
seriously to get the warm fuzzy feeling that the merge wasn't an
accidental mis-merge (by seeing that the code seems to match the brief
description).
Personally, I like to include the entire message to prevent having to
scan the logs for the original commit(s), however, an alternative would
be to have the MFC include a URL to the original commit. Two options
would be:
1. Automatic insertion into log message with a Subversion hook which
adds a URL from scanning a special code in the MFC message (MFC
r12345,12346-12349). Of course, this takes more initial setup and
education for committers (at least me :)) to use it correctly.
2. Committer can use a special base URL that is agreed to never change.
This would make it easier to find the original log message without
having to scan for it.
Sean
--
s...@freebsd.org
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"