Identifying user who ran “git reset” command

I came across a problem recently. One of the developers committed some
changes in a branch. When he checked the branch log (git checkout branch;
git log), the commit (say, abc) was showing up but when he checked the log
for a file (git log <file_name>), which was part of the given commit (abc),
the associated commit (abc) was not showing up; instead, an older commit id
(say, xyz) was there.

When the issue came to my notice, I tried using "git log --follow
<file_name>" to check complete history of a file just to make sure whether
the file was renamed to its current name. The output of "git log --follow
<file_name>" was actually showing the commit id (abc) that was missing in
the output of "git log <file_name>" command. On asking developer whether the
file was renamed, i came to know that no renames were done ever for that
file. This was confusing and i was stuck because i was not able to figure
out what happened. Later, it turned out that another developer while pushing
his code encountered merge conflict and instead of resolving it, he simply
did a "git reset ." and the HEAD got shifted.

Q.1) Is there any way i could have figured out about the "git reset" command
that the other developer executed on his machine? FYI, i have admin access
to Git.

Q.2) Is there any way we can control such things from happening in future?
I’m not sure whether this can be controlled using hook because this is not a
‘push’ command. It's something that's being done just before push. Please
correct me if I’m mistaken. The biggest problem that I see here is that
every developer has the rights to commit, which I feel is not right. I feel,
even restricting it cannot be foolproof but it can certainly bring down such
occurrences significantly. Any suggestions?



--
View this message in context: http://git.661346.n2.nabble.com/Identifying-user-who-ran-git-reset-command-tp7625788.html
Sent from the git mailing list archive at Nabble.com.

On Fri, Feb 20, 2015 at 8:46 PM, Technext [off-list ref] wrote:

The biggest problem that I see here is that
every developer has the rights to commit, which I feel is not right.

Hmm, if you have some way to classify developers into two (or more?)
categories, what would you do instead? Allow some to commit, and
what can others do? Show their change to more senior people and
ask them to commit?

That is more or less in a traditional centralized SCM set-up, I think.

With Git, you can do something similar with "rights to push", if you
prefer such a workflow. It would go like this:

 (1) Everybody can commit to their own repository and grow their own
      history. What you want to protect is the shared view of the project
      history, and restricting what people can do in their own playpen is
      unnecessary.

 (2) Senior people can push into the project's central repository, just
      like in the set-up you currently have.

 (3) Junior people can ask senior people to pull from them. Senior
      people will pull their changes, review, and if the changes are
      good, merge them and push the result to the project's central
      repository. Alternatively, junior people can do this asking by
      sending patches to senior people, who will review and then
      apply to their tree and push the result out to the common history.

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)

Also, am i right in thinking that a check cannot be implemented using hooks
or any other similar way? (my second query)



--
View this message in context: http://git.661346.n2.nabble.com/Identifying-user-who-ran-git-reset-command-tp7625788p7625791.html
Sent from the git mailing list archive at Nabble.com.

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).


[1]: https://stackoverflow.com/a/27744011/20261

On 23 Feb 2015, Kevin Daudt wrote:

On Fri, Feb 20, 2015 at 10:16:18PM -0700, Technext wrote:

quoted

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)

quoted

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.