On Wed, 13 Apr 2016 06:43:11 -0700 (PDT) JIMIT JOSHI <[email protected]> wrote:
> Few days ago, One of my team mate done > force push and we lost entire history of commit from the remote > machine. Hopefully we have the up to date local branch in other > developer's machine so things came back to normal in few hours. Git has the so-called "reflog" facility (see `git help reflog`) which logs all events considered to be "drastic HEAD movements" -- that is, when a ref pushed into gets updated in a way it loses certain history it contained. The reflog is enabled by default in "normal" Git repositories -- those used by people to work -- and disabled in "bare" Git repos -- those used to host "public" repositories. The reflog is not merely some sort of text file with summaries about movements of heads, but rather each reflog entry actually points to the "original" state of the entity whose update event was recorded. The reflog keeps these entries around for some (configurable) time which is around 2 weeks or so IIRC. You could enable the reflog in your central bare repositories and then recovering a botched branch wouldn't require reaching for backups as it would be a matter of logging into the server, inspecting the reflog and retargetting the affected branch back to its original point. The potential downside is that if you actually *do* frequent force pushes (this is quite OK for certain workflows) the reflog will clinge onto the old history and your repositories will grow larger. > However, I surprised to see that I couldn't trace the person who did > it. I did the force push by myself in one of fake repo and I noticed > there isn't any alert/notification is given by GIT to user that be > CAREFUL with it. It really helps to alert person before executing > destructive command. > > I have googled on how to identify the person who did force push and > got > http://stackoverflow.com/questions/15028246/how-can-i-find-out-who-force-pushed-in-git. > So isn't there any out of the box mechanism to get to know the > villain here. There's actually nothing to be surprised about: Git was explicitly designed in a way to abstrain itself from managing authentication, authorization and access controls. Hence, when a Git process is being run to serve a push to a repository (or a fetch from it) it has no idea about the identity -- whatever it could mean -- of the user who is accesing that repository. That is, Git assumes some other software handled the authentication+authorization+access controlling tasks. As to what to do about this in your particular case, highly depends on your setup. Say, if you're using some front-end to Git, such as gitolite or gitlab or something similar, that front-end in most cases already has auditing information available in some form. If you're using "plain" Git with access to it served by an SSH or HTTP server, then the first thing is that these servers usually log access to the resources they serve as well. The second thing is that you could install a special script or program called "hook" (see `git help hooks`) into your repository for the "update" or "post-receive" event and use it to log whatever information is available (say, both SSH and HTTP server with enabled authentication usually provide the authenticated user's name in an environment variable). Of course, you can also just disable non-fast-forward pushes completely to not deal with such a problem in the first place. This is done by setting the receive.denyNonFastForwards config variable in the repository. I should add that in my opinion, I'd better work towards having a written down policy on how to use the public repositories, *explained* and handed down to your developers. I mean, if a developer tries a push which fails, and so they simple-mindedly "re-try" it with the "--force" command-line option (or some check box ticked in some GUI client) then that developer was not properly trained because they did not think about the reason their normal push failed. I mean, it's like trying to have some technical means to prevent drivers from driving on the opposite side of the road; instead, the drivers should be trained to drive on the correct side of the road before their driving license is issued. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
