-extras commit messages

[Sean T Evans]

I'd like to suggest that when committing to Habari-Extras, developers
preface their commit message with the type and name of the item they're
updating (ie Plugin:CreditDue or Theme:Charcoal) this will, I think,
help when reviewing the activity.
--
Sean T Evans

[Michael C. Harris]

Good idea. I don't know enough about the ins and outs of subversion
configuration; is it possible to reject a commit based on the commit
message, and send a custom response?

--
Michael C. Harris, School of CS&IT, RMIT University
http://twofishcreative.com/michael/blog

[Graham Christensen]

I'm pretty confident it is ,with a pre-commit hook (or similar)

Graham

Graham Christensen

http://itrebal.com - Customized Web Hosting
Graham.Ch...@iamgraham.net

[Ali B.]

I agree that It's a very good idea (although I don't add much informative comments myself). It's better than relying on the reader to figure out which plugins/themes where updated by reading what files has changed. It is also a good idea to have the svn rejects the commit if the comment does not start with either 'Theme:' or 'Plugin:'.

--
Ali B.

"No one can make you feel inferior without your consent."
--  Eleanor Roosevelt

[Michael C. Harris]

On Sun, Feb 24, 2008 at 09:58:59PM -0500, Sean T Evans wrote:
>

Attached is a pre-commit hook that will reject commits with PHP syntax
errors (via [1], and probably useful for the main repo too) or that do
not start with plugin: or theme:.

It's just a start, and could be extended to check that the theme or
plugin actually exists in the repository (by checking against the path
reported by svnlook changed). Of course committing new themes or
plugins would have to be taken into account somehow.

Paths will need to be changed to the appropriate locations.

[1] http://www.gmta.info/publications/php-syntax-check-through-subversion-pre-commit-hook

[Scott Merrill]

> echo "***********************************" 1>&2
> echo "PHP error in: ${FILE}:" 1>&2
> echo "$MESSAGE" | sed "s| -| $FILE|g" 1>&2
> echo "***********************************" 1>&2
> exit 1

I think this is a very cool idea, but I wonder if we're doing this the
wrong way around: wouldn't it be better to require people to test
their code prior to checkin, rather than rely on us to do the testing
for them?

Moreover, I worry that this would stifle some blasts of innovation
where someone wants to check in a known broken piece of code so that
they don't lose their place in the development cycle; or even just to
make it available for others to collaborate / fix.

> echo "***********************************" 1>&2
> echo "Start of log message must identify theme or plugin. For example:" 1>&2
> echo "plugin:nicedit" 1>&2
> echo "or" 1>&2
> echo "theme:charcoal" 1>&2
> echo "$MESSAGE" 1>&2
> echo "***********************************" 1>&2
> exit 1

This is an excellent idea.

I've seen people use pre-commit hooks to validate coding style
conventions, so that no TAB characters get inserted into the code (to
enforce a common indentation format, for example). Are there other
ways we could use a pre-commit hook to help us keep the code in shape?

[Michael C. Harris]

On Wed, Mar 05, 2008 at 02:28:01PM -0500, Scott Merrill wrote:
>
> > echo "***********************************" 1>&2
> > echo "PHP error in: ${FILE}:" 1>&2
> > echo "$MESSAGE" | sed "s| -| $FILE|g" 1>&2
> > echo "***********************************" 1>&2
> > exit 1
>
> I think this is a very cool idea, but I wonder if we're doing this the
> wrong way around: wouldn't it be better to require people to test
> their code prior to checkin, rather than rely on us to do the testing
> for them?

Of course, this is just a backup if people don't test. Syntax errors
have been committed before.

> Moreover, I worry that this would stifle some blasts of innovation
> where someone wants to check in a known broken piece of code so that
> they don't lose their place in the development cycle; or even just to
> make it available for others to collaborate / fix.

I'll leave that as open for discussion. Personally, I don't think the
repo is the right place to collaboratively debug syntactically
incorrect code, and I doubt that a flurry of innovation is what causes
most syntax errors.

> > echo "***********************************" 1>&2
> > echo "Start of log message must identify theme or plugin. For example:" 1>&2
> > echo "plugin:nicedit" 1>&2
> > echo "or" 1>&2
> > echo "theme:charcoal" 1>&2
> > echo "$MESSAGE" 1>&2
> > echo "***********************************" 1>&2
> > exit 1
>
> This is an excellent idea.
>
> I've seen people use pre-commit hooks to validate coding style
> conventions, so that no TAB characters get inserted into the code (to
> enforce a common indentation format, for example). Are there other
> ways we could use a pre-commit hook to help us keep the code in shape?

Apparently Drupal has such a script. I'm sure we could write something
that ensured coding style. Or, instead of being so strict as to reject
outright, we could output messages suggesting the committer run such a
script, include more commenting, etc etc.