From: Jeff King <peff@peff.net>
Date: Thu, 14 Nov 2013 11:09:38 GMT
Subject: Re: can we prevent reflog deletion when branch is deleted?
Message-ID: <20131114110937.GA11597@sigill.intra.peff.net>
In-Reply-To: <5284AC6E.4030208@gmail.com>

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.

-Peff