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 <varuag.chhabra@gmail.com> wrote:

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:

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)

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:

operations

to

automated in a

changes

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.