[PATCH] Implement --strict flag for commit

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David Allouche wrote:
> On Tue, 2005-10-18 at 09:17 -0400, Aaron Bentley wrote:
>>I disagree that either strict or loose can cause the contributor to
>>submit changes that are invalid to the maintainer.  --strict only
>>applies to the working tree.
> 
> 
> You have point, I was a bit vague with that "valid" thing. Here's a
> concrete example:
> 
> The Maintainer is a Strict guy and likes test case that clean up after
> themselves, but the Contributor writes a test case that leaves some junk
> around.

Okay, that's valid if we look at non-bzr ways of creating unversioned
files.  And so policy differences wrt clean trees do matter.

> Now, if the Contributor is Loose, but strict commit is a branch setting,
> then the Contributor will notice the issue, but still has the option to
> add the junk file to the ignores. In that case, merging the change and
> running the test suite won't prevent the Maintainer from committing, but
> the change is still invalid, because it does not comply with the
> Maintainer's policy that test cases must clean up after themselves.

I think there's a middle ground here;
The contributor is happy, even eager to comply with policy.  It's just
that he's not an expert on bzr, and doesn't know about the per-user
strict setting.  There's a per-branch setting, so the contributor
notices the bug in the test case and fixes it.

So I think this can be viewed as an issue of sane defaults.  The
contributor can always nuke the per-branch setting (and this will not
affect the maintainer's per-branch setting) or do other weird stuff, but
by and large, most people aren't jerks and will only violate project
policy by accident.

I'd even go so far as to suggest that bzr might have a few built-in
commit tests;

./bzr/branch.config
[COMMIT_RULES]
unknowns = No
max_columns = 79
# Permitted values are 'yes', 'no', or 'makefile_only'
tab_indent = makefile_only
check = changed_files
pychecker = No

[SUGGESTED_COMMIT_RULES]
# These rules were present in your upstream branch, but may not be
# secure. If you trust your upstream, move them into your
# COMMIT_RULES section.

check_script = 'project-style.py'

> The bottom line is, per-branch strictness is ineffective as enforcing
> policy. The proper place to enforce policy is the review process. But
> per branch policy can be an annoyance when Maintainer and Contributor
> have differing tastes, tools or development methods.

I think it's a very short-lived annoyance.  The contributor can always
change a policy they dislike.  I think automating the hell out of these
things reduces friction by making it easier to comply with project policy.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDVlAU0F+nu1YWqI0RAodgAJ96dSOMaz8dNSR66iwLh0CRLbwb7ACfbiaL
H5S+ME2Rqv/YJDZNVbk2A/w=
=2AbY
-----END PGP SIGNATURE-----