On Fri, 4 May 2007, Michael Niedermayer wrote: > > we have a nice svn policy which explains that, also people wont receive > write access without having submitted a few clean patches first > so i dont know if more education would really help, the problems are IMHO > rather caused by a mix of lazyness, arrogance and plain oversight > but please dont missunderstand, these problems are not that common, its > rather once every few month [ I was away for a few days, so others probably answered already ... ] With git, the right way to do thigns is to not ever give "write access" to the "standard" tree to developers, but to make each developer have their own tree, and then one or more developers are the ones that merge other peoples work. Since I'm the one who does the merging for the kernel, I've made damn sure that merging other peoples work is as easy as humanly possible, so that I can just sit there, sipping my foofy tropical drink, drunk as a skunk and enjoying every moment of seeing my peons work their little fingers to the bone, when I do a "git pull ..." and in two seconds I've downloaded their work and merged it, and I can take another sip of the Piña Colada. Burp. And git also makes it really easy to see when somebody does something stupid. The one thing it always shows to the person doing the merging is the diffstat from the result, so if somebody re-indented the source base, the merger goes "Whaa", and assuming he's not too drunk to type, he should just send a sternly worded message to the developer who did the bad deed, and tell them that their work was unacceptable, and won't be pulled. A simple "git reset --hard ORIG_HEAD" will undo the merge, so the person(s) who actually does the integration again doesn't actually have to work all that hard. In other words, the proper sequence really should be to *not* let the horribly buggy commits into the standard version in the first place! Sure, individual developers will make mistakes, but the fact that they screwed up should in _no_ way mean that they can screw up the main repository. The whole point in being distributed is that developers can screw up in their own _private_ repositories and still have all the power of a proper SCM tool, but without actually getting to screw up the main repo. (And yes, then very occasionally both the developer *and* the maintainer screws up, and something bad gets through, and yeah, then you need to revert, but the point I'm arguing is that with a fairly good flow of development, you don't have to worry about the more clueless people screwing up - they can still do development, and you can still pull from them, but *if* they screw up, you can tell them to clean up their mess *before* you actually put it into any standard tree, and the mess can be entirely their _local_ mistake and never visible anywhere else). Linus