Re: can we prevent reflog deletion when branch is deleted?

[Sitaram Chamarty <sitaramc@gmail.com>]

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
>