A feature like this makes a lot of for a Git hosting service. Good to see that we are neither the first nor the only one to cause a trouble like this [1].
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=361707 On 11/12/2013 03:19 AM, Dariusz Łuksza wrote:
In CollabNet we already implemented so called History Protection. We already put some thoughts on this topic and come up with solution for unintended force pushes and branch deletion. Maybe you can reuse some of our approaches. Here is short description of this feature. History Protection it is an extension to Gerrit Code Review that will create special ref when ever somebody is deleting a branch or force pushing. When force push occur our plugin will create a special ref in refs/rewrites. This ref will point to old version of branch and it's name will contain additional informations like rewritten branch name, sha-1 of new head commit, timestamp and name of user that actually did this push. Same goes for branch deletion, but in that case new ref will be created in refs/deleted. Our plugin is also blocking write access to refs/rewrite and refs/deleted (therefore no body can modify them), but anybody can read those refs to be able recreate deleted/overwritten history. Other then that it will send email to Gerrit Administrators group and put entry in audit log. You can find more about this in my blog posts[1][2] and youtoube video[3] [1] http://luksza.org/2012/cool-git-stuff-from-collabnet-potsdam-team/ [2] http://blogs.collab.net/git/protect-git-history [3] https://www.youtube.com/watch?v=z_FN1NvneBw On Tuesday, November 12, 2013 7:25:32 AM UTC+1, Kohsuke Kawaguchi wrote: Now that the commits have been recovered and things are almost back to normal, I think it's time to think about how to prevent this kind of incidents in the future. Our open commit access policy was partly made possible by the idea that any bad commits can be always rolled back. But where I failed to think through was that the changes to refs aren't by themselves version controlled, and so it is possible to lose commits by incorrect ref manipulation, such as "git push -f", or by deleting a branch. I still feel strongly that we maintain the open commit access policy. This is how we've been operating for the longest time, and it's also because otherwise adding/removing developers to repositories would be prohibitively tedious. So my proposal is to write a little program that uses GitHub events API to keep track of push activities in our repositories. For every update to a ref in the repository, we can record the timestamp, SHA1 before and after, the user ID. We can maintain a text file for every ref in every repository, and the program can append lines to it. In other words, effectively recreate server-side reflog outside GitHub. The program should also fetch commits, so that it has a local copy for every commit that ever landed on our repositories. Doing this also allows the program to detect non fast-forward. It should warn us in that situation, plus it will create a ref on the commit locally to prevent it from getting lost. We can then make these repositories accessible via rsync to encourage people to mirror them for backup, or we can make them publicly accessible by hosting them on GitHub as well, although the latter could be confusing. WIth a scheme like this, pushes can be safely recorded within a minute or so (and this number can go down even further if we use webhooks.) If a data loss occurs before the program gets to record newly pushed commits, we should still be able to record who pushed afterward to identify who has the commits that were lost. With such a small time window between the push and the record, the number of such lost commits should be low enough such that we can recover them manually. -- Kohsuke Kawaguchi -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" 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/groups/opt_out.
-- Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/ Try Jenkins Enterprise, our professional version of Jenkins -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" 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/groups/opt_out.
