Barry Smith <[email protected]> writes: >> On the Reported-by tags, could you do them in a structured way as >> >> Reported-by: Matteo Parsani <[email protected]> >> Reported-by: Lisandro Dalcin <[email protected]> > > This is fine, but there needs to be a mechanism to ensure this,
We already have whitespace conventions, a convention that there are no memory leaks, a convention that type-specialized functions use dynamic composition, a convention that we do not create dependency loops, a function naming convention, a convention about avoiding globals, a branch usage convention, etc. None of these are enforced and only some have automated checking. > imposing requirements on developers that do not have enforcement > mechanisms (besides being yelled at later) don't work. Patch review is more flexible than any automated tool can be. It is only time to write an automated tool when the effort to do so, and the attainable accuracy, is a better use of human time than had the same time been devoted to patch review. Note that patch review can catch many things, but automated tools can only catch that which has been automated. > Note that this is the same kind of situation as me accidentally > editing directly into maint. I did > > git branch barry/fix-matmpibaijsetpreallocationcsr This creates a branch without checking it out. If you want to create the branch _and_ check it out, use $ git checkout -b barry/fix-matmpibaijsetpreallocationcsr > happily edited away and tested > git commit -a > git push > > Now what should have happened is as soon as I tried to happily edit > away, something should come back and said to me: "are you sure you > want to edit in maint?" This is policy on the branch rather than the fact that you created a new branch prior to starting this work. (I do that sometimes so that I'll be able to easily compare to the old state later.) We could perhaps prevent direct commits on 'maint'. > And don't go and mail me some elisp that I can stick in somewhere to > warn me about the maint editing business; that would only solve the > problem for me, not for the n-1 other people in the world who make the > same mistake. Git needs some way of "baking in" a set of standards > (optional obviously) that it does its best to enforce and not leaving > it up to each user to remember 324 things they need to constantly be > checking depending on what project they are working on. There is a security problem with making normal commands behave differently when run inside some repository that you just cloned. Any such policy would need to be opt-in.
pgpviAP8DRlmV.pgp
Description: PGP signature
