On 11/14/2013 04:39 PM, Jeff King wrote: > On Thu, Nov 14, 2013 at 04:26:46PM +0530, Sitaram Chamarty wrote: > >>> I do not know about any particular debate in git circles, but I assume >>> Sitaram is referring to this incident: >>> >>> https://groups.google.com/d/msg/jenkinsci-dev/-myjRIPcVwU/t4nkXONp8qgJ >>> >>> in which a Jenkins dev force-pushed and rewound history on 150 different >>> repos. In this case the reflog made rollback easy, but if he had pushed >>> a deletion, it would be harder. >> >> I don't know if they had a reflog on the server side; they used >> client-side reflogs if I understood correctly. >> >> I'm talking about server side (bare repo), assuming the site has >> core.logAllRefUpdates set. > > Yes, they did have server-side reflogs (the pushes were to GitHub, and > we reflog everything). Client-side reflogs would not be sufficient, as > the client who pushed does not record the history he just rewound (he > _might_ have it at refs/remotes/origin/master@{1}, but if somebody > pushed since his last fetch, then he doesn't). > > The "simplest" way to recover is to just have everyone push again > (without --force). The history will just silently fast-forward to > whoever has the most recent tip. The downside is that you have to wait > for that person to actually push. :) > > I think they started with that, and then eventually GitHub support got > wind of it and pulled the last value for each repo out of the > server-side reflog for them. Great. But what does github do if the branches were *deleted* by mistake (say someone does a "git push --mirror"; most likely in a script, for added fun and laughs!) Github may be able to help people recover from that also, but plain Git won't. And that's what I would like to see a change in. > > -Peff > -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html