On 23 Feb 2015, Kevin Daudt wrote: > On Fri, Feb 20, 2015 at 10:16:18PM -0700, Technext wrote: > > Thanks Junio for the prompt reply! :) Yes, that's exactly how i would > > like things to be. I'll definitely try to push this thing and see if > > this flow can be implemented. > > However, can you please guide me whether there's any way i could have > > figured out about the git reset command that the developer executed on > > his local? (my first query) > > git reset . is just a local working tree operation, which does not leave > something behind, just like when the user would do any other file operations > and comitted that. This created a so called evil merge, which are not easy to > detect (see [1] for some possible solutions) > > > > > Also, am i right in thinking that a check cannot be implemented using > > hooks or any other similar way? (my second query) > > Because an evil merge is hard to detect, it's even harder to do it automated in a > script. Human review works much better for this (when merging in the changes > from the developer). The only effective way I have found to deal with this is to have an implemented policy of making sure that developers only push changes to topic branches and have an approver handle the merge. This will not eliminate the evil merge or reset, but at least you get a second set of eyes on it. With that said, the oops merge or reset is different, which an accidental operation. I know it is off-topic, but there is an approach used by other systems (some code-management, some not) that implement per-command policies. Something like a client-side hook or config-like access control list may be useful: like a hooks/pre-execute (invoked possibly as high up as in run_argv() after handle_options()) that gets passed argv, and is able to accept/decline the command, might catch accidents. Granted this slows things down a whole lot, but places that use (I didn't say need) command-level restrictions, often are willing to accept performance degradation and the resulting grumbling that comes with it. And you've probably had this discussion before, so I sincerely apologize in advance for bringing it up. Cheers, Randall -- Brief whoami: NonStop&UNIX developer since approximately UNIX(421664400)/NonStop(211288444200000000) -- In real life, I talk too much. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html