Last night's Perlmongers meeting was fun -- in September, we do Lightning Talks (not strictly limited to five minutes), which give everyone a chance to do a mini-presentation.
The discussion after Olaf Alder's presentation on Code::TidyAll touched on how to insure that developers only committed and checked in code that passed certain style rules. I'm curious to find out what my fellow monks feel about that.
At my last job, I was the git administrator, and I set up git hooks for some of the important repositories such that the commit message would be searched for a JIRA ticket number. If found, the script used the JIRA API to update that ticket with information about the commit, including a link to the commit (via gitweb). Theoretically, each commit should have had a JIRA ticket number, but if one wasn't found, the git hook script just output a message reminding the developer that their commit should have included an issue number.
I could have just disallowed the git push command altogether, forcing the developer game the system by using a fake JIRA number (ABC-1234) or perhaps some unrelated ticket number, but I wanted to avoid having the developers try to game the system in order to get their work into the repository. (I should also mention that the build system pulled only from the repository.)
What are your thoughts? How far should the revision control system go to enforcing a particular style and level of documentation?
In reply to Setting boundaries in software development by talexb
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |