RE: Identifying user who ran "git reset" command

["Randall S. Becker" <rsbecker@nexbridge.com>]

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.