On Wed, 13 Apr 2016 06:43:11 -0700 (PDT)
JIMIT JOSHI <joshiji...@gmail.com> 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
> 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
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
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
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
For more options, visit https://groups.google.com/d/optout.