Identifying user who ran “git reset” command

Identifying user who ran “git reset” command

[Technext]

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.

Re: Identifying user who ran “git reset” command

[Junio C Hamano]

On Fri, Feb 20, 2015 at 8:46 PM, Technext <varuag.chhabra@gmail.com> 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.

Re: Identifying user who ran “git reset” command

[Technext]

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.

Re: Identifying user who ran “git reset” command

[Kevin Daudt]

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

RE: Identifying user who ran "git reset" command

[Randall S. Becker]

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.

Re: Identifying user who ran “git reset” command

[Gaurav Chhabra]

First of all, my sincere apologies for the inordinate delay in reply.
The user who created the mess went on leave. By the time he was back,
I got stuck in some other issue. Later, I took the log of 'history'
command from his machine because i wanted to first simulate the
scenario before i could apply Alfred's check to see whether it works.

I tried simulating the scenario but couldn't reproduce it. :( Here's
the PASTEBIN link which details what the developer did and how i tried
simulating the same: http://pastebin.com/0GkSc59y

As you will notice from the above link, in the original case, the
developer got "Your branch is ahead of 'origin/some_branch' by 2
commit." message while in my simulation, i got "Your branch and
'origin/some_branch' have diverged, and have 1 and 1 different commit
each, respectively."

Not only is the message different, in the simulation, i can actually
see the user's (in this case, harry) detail in 'git log' command. In
the original case, the log did not contain any info on the user who
messed up history.

Although i did suspect that Alfred's suggestion might not actually
address this issue but i still wanted to confirm it. However, thanks
Alfred because it did solve another issue (disabling "force push") for
which i was planning to put a check. :)

@Randall/Kevin: The type of setup you suggested will definitely be
ideal but in the type of environment we operate, i'm highly skeptical
whether it will be implemented. :) I surely will highlight the issue
and its impact though. As Gergely earlier mentioned, i guess i will
have to capture ref updates. I never really looked into 'refs' before
but now i will have to. I'm sure it will help me customize many other
things as well especially access-related stuff.


Thanks again to Junio, Gergely, Alfred, Randall and Kevin for their inputs. :)